Qual è il modo più sicuro per scrivere a livello di codice su un file con privilegi di root?

Un'enorme applicazione deve, in un determinato momento, eseguire un piccolo numero di scritture su un file che richiede i permessi di root. Non è in realtà un file ma un'interfaccia hardware che è esposta a Linux come file.

Per evitare di dare i privilegi di root all'intera applicazione, ho scritto uno script bash che svolge i compiti critici. Ad esempio, il seguente script abiliterà la porta 17 dell'interfaccia hardware come output:

echo "17" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio17/direction

Tuttavia, poiché suidè disabilitato per gli script bash sul mio sistema, mi chiedo quale sia il modo migliore per raggiungere questo obiettivo.

1. Usa una soluzione alternativa presentata qui

2. Chiamare lo script con sudodall'applicazione principale e modificare di conseguenza l'elenco dei sudoers, per evitare di richiedere una password quando si chiama lo script. Sono un po 'a disagio a dare i privilegi di sudo echo.

3. Basta scrivere un programma C, con fprintfe impostarlo su suid root. Hardcode le stringhe e i nomi dei file e assicurarsi che solo root possa modificarlo. Oppure leggi le stringhe da un file di testo, allo stesso modo assicurandoti che nessuno possa modificare il file.

4. Qualche altra soluzione che non mi è venuta in mente ed è più sicura o più semplice di quelle presentate sopra?

Non devi dare sudo accesso a echo. In effetti, è inutile perché, ad esempio con sudo echo foo > bar, il reindirizzamento viene eseguito come utente originale, non come root.

Chiama il piccolo script con sudo , consentendo l' NOPASSWD:accesso SOLO a quello script (e a qualsiasi altro script simile) da parte degli utenti che hanno bisogno di accedervi.

Questo è sempre il modo migliore / più sicuro da usare sudo. Isolare il piccolo numero di comandi che richiedono i privilegi di root nei propri script separati e consentire all'utente non fidato o parzialmente fidato di eseguire solo quello script come root.

Il piccolo sudo script di ridotte non devono prendere args (o input) dall'utente (ovvero qualsiasi altro programma che chiama dovrebbe avere opzioni e args codificate) oppure dovrebbe validare con molta attenzione qualsiasi argomento / input che deve accetta dall'utente.

Sii paranoico nella convalida - piuttosto che cercare cose "conosciute cattive" da escludere, consentire solo cose "conosciute buone" e interrompere qualsiasi discrepanza o errore o qualsiasi cosa anche lontanamente sospetta.

La convalida dovrebbe avvenire il più presto possibile nello script (preferibilmente prima di fare qualsiasi altra cosa come root).

Avrei davvero dovuto menzionarlo quando ho scritto questa risposta per la prima volta, ma se il tuo script è uno script shell DEVE citare correttamente tutte le variabili. Prestare particolare attenzione a citare le variabili contenenti l'input fornito dall'utente in alcun modo, ma non dare per scontato che alcune variabili siano sicure, PREVENTILO TUTTI .

Ciò include le variabili di ambiente potenzialmente controllate dall'utente (ad es "$PATH". "$HOME", "$USER"Ecc. E sicuramente incluse "$QUERY_STRING"ed "HTTP_USER_AGENT"ecc. In uno script CGI). In effetti, citali tutti. Se devi costruire una riga di comando con più argomenti, usa un array per costruire l'elenco args e citare che -"${myarray[@]}" .

Ho già detto "citali tutti" abbastanza spesso? ricordalo. fallo.

Controlla il proprietario sui file gpio:

ls -l /sys/class/gpio/

Molto probabilmente, scoprirai che sono di proprietà del gruppo gpio:

-rwxrwx--- 1 root     gpio     4096 Mar  8 10:50 export
...

In tal caso, puoi semplicemente aggiungere il tuo utente al gpiogruppo per concedere l'accesso senza sudo:

sudo usermod -aG gpio myusername

Dovrai disconnetterti e riconnetterti per rendere effettiva la modifica.

Una soluzione per questo (utilizzata in particolare sul desktop Linux ma applicabile anche in altri casi) è utilizzare D-Bus per attivare un piccolo servizio in esecuzione come root e polkit per eseguire l'autorizzazione. Questo è fondamentalmente ciò per cui Polkit è stato progettato ; dalla sua documentazione introduttiva :

polkit fornisce un'API di autorizzazione destinata a essere utilizzata da programmi privilegiati ("MECCANISMI") che offre servizi a programmi non privilegiati ("CLIENTI"). Consulta la pagina di manuale di polkit per l'architettura di sistema e l'immagine generale.

Invece di eseguire il tuo programma di supporto, il grande programma senza privilegi invierebbe una richiesta sul bus. Il tuo helper potrebbe essere in esecuzione come un demone avviato all'avvio del sistema o, meglio, esserlo attivato secondo necessità da systemd . Quindi, quell'helper userebbe polkit per verificare che la richiesta provenga da un luogo autorizzato. (O, in questo caso, se ciò sembra eccessivo, è possibile utilizzare un altro meccanismo di autenticazione / autorizzazione codificato).

Ho trovato un buon articolo di base sulla comunicazione tramite D-Bus e, sebbene non lo abbia ancora testato, questo sembra essere un esempio di base per aggiungere polkit al mix .

In questo approccio, nulla deve essere contrassegnato come setuid.

Un modo per farlo è quello di creare un programma setuid-root scritto in C che faccia solo ciò che è necessario e niente di più. Nel tuo caso, non è necessario esaminare alcun input dell'utente.

#include <unistd.h>
#include <string.h>
#include <stdio.h>  // for perror(3)
// #include ...  more stuff for open(2)

static void write_str_to_file(const char*fn, const char*str) {
    int fd = open(fn, O_WRONLY)
    if (-1 == fd) {
        perror("opening device file");  // make this a CPP macro instead of function so you can use string concat to get the filename into the error msg
        exit(1);
    }
    int err = write(fd, str, strlen(str));
    // ... error check
    err = close(fd);
    // ... error check
}

int main(int argc, char**argv) {
    write_string_to_file("/sys/class/gpio/export", "17");
    write_string_to_file("/sys/class/gpio/gpio17/direction", "out");
    return 0;
}

Non c'è modo di sovvertirlo attraverso variabili d'ambiente o altro, perché tutto ciò che fa è effettuare un paio di chiamate di sistema.

Unico inconveniente: è necessario verificare il valore di ritorno di ogni chiamata di sistema.

Upside: il controllo degli errori è davvero semplice: se c'è qualche errore, basta perrore salvarsi: uscire con stato diverso da zero. Se c'è un errore, indagare con strace. Non è necessario questo programma per fornire messaggi di errore davvero piacevoli.

Bless tee anziché echo per sudo è un modo comune per affrontare una situazione in cui è necessario limitare i permessi di root. Il reindirizzamento a / dev / null è quello di impedire la fuoriuscita di qualsiasi output - il t fa quello che vuoi.

echo "17" | sudo tee /sys/class/gpio/export > /dev/null
echo "out" | sudo tee /sys/class/gpio/gpio17/direction > /dev/null

È possibile creare uno script che esegua l'attività desiderata. Quindi, crea un nuovo account utente che può accedere solo fornendo una chiave utilizzata da OpenSSH.

Nota: chiunque sarà in grado di eseguire quello script se ha il file chiave, quindi assicurati che il file chiave OpenSSH non sia leggibile da chiunque desideri impedire l'esecuzione dell'attività.

Nella configurazione OpenSSH (nel file authorized_keys), prima di specificare la chiave, specificare un comando (seguito da uno spazio), come descritto nel testo "esempio":

command="myscript" keydata optionalComment

Questa opzione di configurazione può limitare la chiave OpenSSH all'esecuzione solo di un comando specifico. Ora hai sudo concedere le autorizzazioni, ma la configurazione OpenSSH è la parte della soluzione che viene realmente utilizzata per limitare / limitare ciò che quell'utente è in grado di fare, in modo che l'utente non stia eseguendo altri comandi. Anche questo non ha un file di configurazione "sudo" così complicato, quindi se usi OpenBSD o se il nuovo "doas" ("do as") di OpenBSD inizia a diventare più popolare (con le versioni future di qualunque sistema operativo che usi) , non dovrai essere sfidato da molta complessità nella configurazione sudo.