SUID, SGID e Sticky Bits sono potenti autorizzazioni speciali che puoi impostare per eseguibili e directory su Linux. Condivideremo i vantaggi e le potenziali insidie del loro utilizzo.
Sommario:
Sono già in uso
Costruire la sicurezza in un sistema operativo multiutente presenta diversi dilemmi. Prendi il concetto (apparentemente) di base delle password, ad esempio. Devono essere tutti memorizzati in modo che ogni volta che qualcuno accede, il sistema possa confrontare la password che digita con la copia memorizzata. Ovviamente, poiché le password sono le chiavi del regno, devono essere salvaguardate.
Su Linux, le password archiviate sono protette in due modi: sono crittografate e solo qualcuno con privilegi di root può accedere al file che contiene le password. Potrebbe suonare bene, ma presenta un dilemma: se solo le persone con privilegi di root possono accedere alle password memorizzate, come fanno coloro che non hanno tale accesso a modificare le proprie password?
Elevare il tuo stato
Di solito, i comandi ei programmi Linux vengono eseguiti con lo stesso insieme di autorizzazioni della persona che avvia il programma. Quando root esegue il comando passwd per modificare una password, funziona con i permessi di root. Ciò significa che il comando passwd può accedere liberamente alle password memorizzate nel file / etc / shadow.
L’ideale sarebbe uno schema in cui chiunque sul sistema possa avviare il programma passwd, ma fare in modo che il programma passwd mantenga i privilegi elevati di root. Ciò consentirebbe a chiunque di modificare la propria password.
Lo scenario precedente è esattamente ciò che fa il bit Set User ID (SUID). It esegue programmi e comandi con le autorizzazioni del proprietario del file, piuttosto che con le autorizzazioni della persona che avvia il programma.
Stai elevando lo stato del programma
C’è un altro dilemma, però. Alla persona deve essere impedito di interferire con la password di qualcun altro. Linux incorpora lo schema SUID che gli consente di eseguire applicazioni con una serie di permessi presi temporaneamente in prestito, ma questa è solo metà della storia della sicurezza.
Il meccanismo di controllo che impedisce a qualcuno di lavorare con la password di un’altra persona è contenuto nel programma passwd, non nel sistema operativo e nello schema SUID.
I programmi eseguiti con privilegi elevati possono comportare rischi per la sicurezza se non vengono creati con una mentalità “security by design”. Ciò significa che la sicurezza è la prima cosa che prendi in considerazione e poi costruisci su quella. Non scrivere il tuo programma e poi prova a dargli una mano di sicurezza in seguito.
Il più grande vantaggio del software open source è puoi guardare tu stesso il codice sorgente o fare riferimento a revisioni tra pari attendibili di esso. Nel codice sorgente del programma passwd ci sono dei controlli, così puoi vedere se la persona che esegue il programma è root. Sono consentite diverse capacità se qualcuno è root (o qualcuno che usa sudo).
Questo è il codice che rileva se qualcuno è root.
Quello che segue è un esempio in cui viene preso in considerazione. Poiché root può modificare qualsiasi password, il programma non deve preoccuparsi dei controlli che di solito esegue per vedere quali password la persona ha il permesso di cambiare. Quindi, per root, esso salta quei controlli ed esce dalla funzione di controllo.
Con i comandi e le utilità principali di Linux, puoi essere certo che hanno una sicurezza integrata e che il codice è stato rivisto molte volte. Ovviamente c’è sempre la minaccia di exploit ancora sconosciuti. Tuttavia, le patch o gli aggiornamenti appaiono rapidamente per contrastare le nuove vulnerabilità identificate.
È software di terze parti, specialmente se non open-source, con cui devi stare estremamente attento nell’usare SUID. Non stiamo dicendo di non farlo, ma, se lo fai, vuoi assicurarti che non esponga il tuo sistema a rischi. Non vuoi elevare i privilegi di un programma che non auto-governerà correttamente se stesso e la persona che lo esegue.
Comandi Linux che utilizzano SUID
Di seguito sono riportati alcuni dei comandi Linux che utilizzano il bit SUID per dare al comando privilegi elevati quando viene eseguito da un utente normale:
ls -l /bin/su
ls -l /bin/ping
ls -l /bin/mount
ls -l /bin/umount
ls -l /usr/bin/passwd
Notare che i nomi dei file sono evidenziati in rosso, che indica che il bit SUID è impostato.
I permessi su un file o una directory sono generalmente rappresentati da tre gruppi di tre caratteri: rwx. Questi stanno per leggere, scrivere ed eseguire. Se le lettere sono presenti, l’autorizzazione è stata concessa. Se è presente un trattino (-) invece di una lettera, l’autorizzazione non è stata concessa.
Esistono tre gruppi di queste autorizzazioni (da sinistra a destra): quelli per il proprietario del file, per i membri del gruppo del file e per gli altri. Quando il bit SUID è impostato su un file, una “s” rappresenta l’autorizzazione di esecuzione del proprietario.
Se il bit SUID è impostato su un file che non ha capacità eseguibili, una “S” maiuscola lo indica.
Diamo un’occhiata a un esempio. L’utente normale dave digita il comando passwd:
passwd
Il comando passwd richiede a dave la sua nuova password. Possiamo usare il comando ps per vedere i dettagli dei processi in esecuzione.
Useremo ps con grep in una finestra di terminale diversa e cerca il processo passwd. Useremo anche le opzioni -e (ogni processo) e -f (formato completo) con ps.
Digitiamo il seguente comando:
ps -e -f | grep passwd
Vengono riportate due righe, la seconda delle quali è il processo grep alla ricerca di comandi contenenti la stringa “passwd”. È la prima riga che ci interessa, però, perché è quella per il processo passwd lanciato da Dave.
Possiamo vedere che il processo passwd viene eseguito come se fosse stato avviato da root.
Impostazione del bit SUID
È facile cambiare il bit SUID con chmod. La modalità simbolica u + s imposta il bit SUID e la modalità simbolica us cancella il bit SUID.
Per illustrare alcuni dei concetti del bit SUID, abbiamo creato un piccolo programma chiamato htg. Si trova nella directory root dell’utente dave e non ha impostato il bit SUID. Quando viene eseguito, visualizza gli ID utente reali ed effettivi (UID).
Il vero UID appartiene alla persona che ha lanciato il programma. L’ID effettivo è l’account da cui il programma si comporta come se fosse stato avviato.
Digitiamo quanto segue:
ls -lh htg
./htg
Quando eseguiamo la copia locale del programma, vediamo che l’ID reale ed effettivo sono entrambi impostati su dave. Quindi, si comporta proprio come dovrebbe fare un normale programma.
Copiamolo nella directory / usr / local / bin in modo che altri possano usarlo.
Digitiamo quanto segue, usando chmod per impostare il bit SUID, e poi controlliamo che sia stato impostato:
sudo cp htg /usr/local/bin
sudo chmod u+s /usr/local/bin/htg
ls -hl /usr/local/bin/htg
Quindi, il programma viene copiato e il bit SUID viene impostato. Lo eseguiremo di nuovo, ma questa volta eseguiremo la copia nella cartella / usr / local / bin:
htg
Anche se dave ha lanciato il programma, l’ID effettivo è impostato sull’utente root. Quindi, se mary lancia il programma, accade la stessa cosa, come mostrato di seguito:
htg
L’ID reale è mary e l’ID effettivo è root. Il programma viene eseguito con le autorizzazioni dell’utente root.
Il bit SGID
Il bit Set Group ID (SGID) è molto simile al bit SUID. Quando il bit SGID è impostato su un file eseguibile, il gruppo effettivo è impostato sul gruppo del file. Il processo viene eseguito con le autorizzazioni dei membri del gruppo del file, piuttosto che con le autorizzazioni della persona che lo ha avviato.
Abbiamo modificato il nostro programma htg in modo che mostri anche il gruppo effettivo. Cambieremo il gruppo del programma htg in modo che sia il gruppo predefinito dell’utente mary, mary. Useremo anche le modalità simboliche us e g + s con chown per rimuovere il bit SUID e impostare SGID.
Per farlo, digitiamo quanto segue:
sudo chown root:mary /usr/local/bin/htg
sudo chmod u-s,g+s /usr/local/bin/htg
ls -lh /usr/local/bin/htg
Puoi vedere il bit SGID indicato dalla “s” nei permessi del gruppo. Inoltre, nota che il gruppo è impostato su mary e il nome del file è ora evidenziato in giallo.
Prima di eseguire il programma, stabiliamo a quali gruppi appartengono Dave e Mary. Useremo il comando id con l’opzione -G (groups), per stampare tutti gli ID di gruppo. Quindi, eseguiremo il programma htg come dave.
Digitiamo i seguenti comandi:
id -G dave
id -G mary
htg
L’ID del gruppo predefinito per mary è 1001 e il gruppo effettivo del programma htg è 1001. Quindi, sebbene sia stato lanciato da dave, funziona con i permessi dei membri del gruppo mary. È come se Dave si fosse unito al gruppo di Mary.
Applichiamo il bit SGID a una directory. Per prima cosa creeremo una directory chiamata “work”, quindi cambieremo il suo gruppo in “geek”. Quindi imposteremo il bit SGID nella directory.
Quando usiamo ls per controllare le impostazioni della directory, useremo anche l’opzione -d (directory) in modo da vedere i dettagli della directory, non il suo contenuto.
Digitiamo i seguenti comandi:
sudo mkdir work
sudo chown dave:geek work
sudo chmod g+s work
ls -lh -d work
Vengono impostati il bit SGID e il gruppo “geek”. Ciò influenzerà tutti gli elementi creati all’interno della directory di lavoro.
Digitiamo quanto segue per entrare nella directory di lavoro, creare una directory chiamata “demo” e controllarne le proprietà:
cd work
mkdir demo
ls -lh -d demo
Il bit SGID e il gruppo “geek” vengono applicati automaticamente alla directory “demo”.
Digita quanto segue per creare un file con l’estensione toccare comando e verificarne le proprietà:
touch useful.sh
ls -lh useful.sh
Il gruppo del nuovo file viene impostato automaticamente su “geek”.
Il bit appiccicoso
La parte adesiva prende il nome dal suo scopo storico. Quando impostato su un eseguibile, indicava al sistema operativo che le parti di testo dell’eseguibile dovevano essere mantenute in scambio, rendendo il loro riutilizzo più veloce. Su Linux, lo sticky bit interessa solo una directory: impostarlo su un file non avrebbe senso.
Quando si imposta lo sticky bit su una directory, le persone possono eliminare solo i file che appartengono a loro all’interno di quella directory. Non possono eliminare i file che appartengono a qualcun altro, indipendentemente dalla combinazione di autorizzazioni dei file impostata sui file.
Ciò consente di creare una directory che tutti e i processi che avviano possono utilizzare come archivio di file condiviso. I file sono protetti perché, ancora una volta, nessuno può eliminare i file di qualcun altro.
Creiamo una directory chiamata “shared”. Useremo la modalità simbolica o + t con chmod per impostare lo sticky bit su quella directory. Vedremo quindi i permessi su quella directory, così come le directory / tmp e / var / tmp.
Digitiamo i seguenti comandi:
mkdir shared
sudo chmod o+t shared
ls -lh -d shared
ls -lh -d /tmp
ls -lh -d /var/tmp
Se è impostato lo sticky bit, il bit eseguibile dell ‘”altro” insieme di permessi del file è impostato su “t”. Anche il nome del file è evidenziato in blu.
Le cartelle / tmp e / var / tmp sono due esempi di directory che hanno tutti i permessi sui file impostati per il proprietario, il gruppo e altri (ecco perché sono evidenziati in verde). Vengono utilizzati come percorsi condivisi per i file temporanei.
Con queste autorizzazioni, chiunque dovrebbe, in teoria, essere in grado di fare qualsiasi cosa. Tuttavia, il bit appiccicoso li sovrascrive e nessuno può eliminare un file che non gli appartiene.
Promemoria
Quello che segue è un rapido elenco di controllo di ciò che abbiamo trattato sopra per riferimento futuro:
SUID funziona solo sui file.
È possibile applicare SGID a directory e file.
È possibile applicare solo il bit appiccicoso alle directory.
Se gli indicatori “s”, “g” o “t” vengono visualizzati in maiuscolo, il bit eseguibile (x) non è stato impostato.