Come usare SUID, SGID e Sticky Bits su Linux

• Dave McKay

  @TheGurkha

• February 26, 2020, 8:00am EDT

SUID, SGID, e Sticky Bits sono potenti permessi speciali che puoi impostare per eseguibili e directory su Linux. Condivideremo i benefici e le potenziali insidie del loro utilizzo.

Sono già in uso

Costruire la sicurezza in un sistema operativo multiutente presenta diversi dilemmi. Prendiamo il concetto (apparentemente) basilare delle password, per esempio. Devono essere memorizzate in modo che ogni volta che qualcuno accede, il sistema può confrontare la password che digita con la copia memorizzata. Ovviamente, dato che le password sono le chiavi del regno, devono essere salvaguardate.

Su Linux, le password memorizzate sono protette in due modi: sono criptate, e solo qualcuno con root privilegi può accedere al file che contiene le password. Questo potrebbe suonare bene, ma presenta un dilemma: se solo le persone con i privilegi di root possono accedere alle password memorizzate, come fanno quelli che non hanno quell’accesso a cambiare le loro password?

Elevare il tuo stato

Di solito, i comandi e i programmi Linux vengono eseguiti con lo stesso set di permessi della persona che lancia il programma. Quando root esegue il comando passwd per cambiare una password, viene eseguito con i permessi di root. Questo significa che il comando passwd può accedere liberamente alle password memorizzate nel file /etc/shadow.

Quello che sarebbe ideale è uno schema in cui chiunque sul sistema potrebbe lanciare il programma passwd, ma il programma passwd mantiene i privilegi elevati di root. Questo permetterebbe a chiunque di cambiare la propria password.

Lo scenario sopra descritto è esattamente quello che fa il bit Set User ID (SUID). Esegue programmi e comandi con i permessi del proprietario del file, piuttosto che i permessi della persona che lancia il programma.

Stai elevando lo stato del programma

C’è un altro dilemma, però. Si deve evitare che la persona si immischi con la password di qualcun altro. Linux incorpora lo schema SUID che permette di eseguire applicazioni con un insieme di permessi temporaneamente presi 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 che girano con privilegi elevati possono presentare rischi per la sicurezza se non sono creati con una mentalità “security by design”. Questo significa che la sicurezza è la prima cosa da considerare, e poi ci si costruisce sopra. Non scrivete il vostro programma e poi cercate di dargli una mano di sicurezza in seguito.

Il più grande vantaggio del software open source è che potete guardare voi stessi il codice sorgente o fare riferimento a revisioni di pari livello. Nel codice sorgente del programma passwd, ci sono dei controlli, così si può vedere se la persona che esegue il programma è root. Sono permesse diverse capacità se qualcuno è root (o qualcuno che usa sudo).

Questo è il codice che rileva se qualcuno è root.

Questo è un esempio in cui si tiene conto di questo. Poiché root può cambiare 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, salta quei controlli ed esce dalla funzione di controllo.

Con i comandi e le utilità principali di Linux, potete essere sicuri che hanno la sicurezza incorporata e che il codice è stato rivisto molte volte. Naturalmente, c’è sempre la minaccia di exploit ancora sconosciuti. Tuttavia, le patch o gli aggiornamenti sono veloci ad apparire per contrastare qualsiasi nuova vulnerabilità identificata.

È il software di terze parti, specialmente quello che non è open-source, che dovete stare estremamente attenti ad usare SUID. Non stiamo dicendo di non farlo, ma, se lo fate, volete essere sicuri che non esporrà il vostro sistema al rischio. Non volete elevare i privilegi di un programma che non ha intenzione di autogovernare correttamente se stesso e la persona che lo esegue.

Comandi Linux che usano SUID

Questi sono alcuni dei comandi Linux che usano il bit SUID per dare al comando privilegi elevati quando 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

Nota i nomi dei file sono evidenziati in rosso, il che indica che il bit SUID è impostato.

I permessi su un file o una directory sono solitamente rappresentati da tre gruppi di tre caratteri: rwx. Questi stanno per leggere, scrivere ed eseguire. Se le lettere sono presenti, quel permesso è stato concesso. Se è presente un trattino (-) invece di una lettera, però, quel permesso non è stato dato.

Ci sono tre gruppi di questi permessi (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 il permesso di esecuzione del proprietario.

Se il bit SUID è impostato su un file che non ha capacità eseguibili, una “S” maiuscola lo denota.

Vediamo un esempio. L’utente regolare dave digita il comando passwd:

passwd

Il comando passwd chiede a dave la sua nuova password. Possiamo usare il comando ps per vedere i dettagli dei processi in esecuzione.

Utilizzeremo ps con grep in un’altra finestra del terminale e cercheremo il processo passwd. Useremo anche le opzioni -e (ogni processo) e -f (formato completo) con ps.

Scriviamo il seguente comando:

ps -e -f | grep passwd

Sono riportate due righe, la seconda delle quali è il processo grep che cerca comandi con la stringa “passwd”. È la prima linea che ci interessa, però, perché è quella del processo passwd lanciato da dave.

Possiamo vedere che il processo passwd funziona come se root lo avesse lanciato.

Impostazione del bit SUID

È facile cambiare il bit SUID con chmod. Il modo simbolico u+s imposta il bit SUID e il modo simbolico u-s cancella il bit SUID.

Per illustrare alcuni dei concetti del bit SUID, abbiamo creato un piccolo programma chiamato htg. È nella directory principale dell’utente dave, e non ha il bit SUID impostato. Quando viene eseguito, mostra gli ID utente reali ed effettivi (UID).

L’UID reale appartiene alla persona che ha lanciato il programma. L’ID effettivo è l’account con cui il programma si comporta come se fosse stato lanciato.

Scriviamo quanto segue:

ls -lh htg

./htg

Quando eseguiamo la copia locale del programma, vediamo che l’ID reale e quello effettivo sono entrambi impostati su dave. Quindi, si sta comportando proprio come dovrebbe fare un programma normale.

Copiamolo nella directory /usr/local/bin in modo che altri possano usarlo.

Scriviamo 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 è 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, succede la stessa cosa, come mostrato sotto:

htg

L’ID reale è mary, e l’ID effettivo è root. Il programma viene eseguito con i permessi dell’utente root.

RELATO: Come usare il comando chmod su Linux

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 i permessi dei membri del gruppo del file, piuttosto che i permessi della persona che lo ha lanciato.

Abbiamo modificato il nostro programma htg in modo che mostri anche il gruppo effettivo. Cambieremo il gruppo del programma htg per essere il gruppo predefinito dell’utente mary, mary. Useremo anche i modi simbolici u-s e g+s con chown per rimuovere il bit SUID e impostare il SGID.

Per fare ciò, 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

Potete vedere il bit SGID denotato dalla “s” nei permessi del gruppo. Inoltre, notate che il gruppo è impostato su mary e il nome del file è ora evidenziato in giallo.

Prima di eseguire il programma, stabiliamo a quali gruppi dave e mary appartengono. Useremo il comando id con l’opzione -G (gruppi), per stampare tutti gli ID dei gruppi. Poi, eseguiremo il programma htg come dave.

Scriviamo 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, anche se è stato lanciato da dave, è in esecuzione con i permessi dei membri del gruppo mary. È come se dave si fosse unito al gruppo mary.

Applichiamo il bit SGID a una directory. Per prima cosa, creeremo una directory chiamata “work”, e poi cambieremo il suo gruppo in “geek”. Imposteremo quindi il bit SGID sulla directory.

Quando usiamo ls per controllare le impostazioni della directory, useremo anche l’opzione -d (directory) così vedremo i dettagli della directory, non il suo contenuto.

Scriviamo i seguenti comandi:

sudo mkdir work

sudo chown dave:geek work

sudo chmod g+s work

ls -lh -d work

Il bit SGID e il gruppo “geek” sono impostati. Questi influenzeranno qualsiasi elemento creato all’interno della directory work.

Scriviamo quanto segue per entrare nella directory work, creare una directory chiamata “demo” e controllare le sue proprietà:

cd work

mkdir demo

ls -lh -d demo

Il bit SGID e il gruppo “geek” sono automaticamente applicati alla directory “demo”.

Scriviamo quanto segue per creare un file con il comando touch e controllare le sue proprietà:

touch useful.sh

ls -lh useful.sh

Il gruppo del nuovo file è automaticamente impostato su “geek.”

RELATO: Come usare il comando chown su Linux

Il bit adesivo

Il bit adesivo prende il nome dal suo scopo storico. Quando è impostato su un eseguibile, segnala al sistema operativo che le porzioni di testo dell’eseguibile dovrebbero essere tenute in swap, rendendo il loro riutilizzo più veloce. Su Linux, il bit appiccicoso ha effetto solo su una directory – impostarlo su un file non avrebbe senso.

Quando si imposta il bit appiccicoso su una directory, le persone possono cancellare solo i file che gli appartengono all’interno di quella directory. Non possono cancellare i file che appartengono a qualcun altro, non importa quale combinazione di permessi sia impostata sui file.

Questo vi permette di creare una directory che tutti, e i processi che lanciano, possono usare come archivio condiviso di file. I file sono protetti perché, di nuovo, nessuno può cancellare i file di qualcun altro.

Creiamo una directory chiamata “shared”. Useremo il modo simbolico o+t con chmod per impostare il bit adesivo su quella directory. Guarderemo poi i permessi su quella directory, così come sulle directory /tmp e /var/tmp.

Scriviamo i seguenti comandi:

mkdir shared

sudo chmod o+t shared

ls -lh -d shared

ls -lh -d /tmp

ls -lh -d /var/tmp

Se il bit adesivo è impostato, il bit eseguibile dell'”altro” set di permessi dei 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 di file impostati per il proprietario, il gruppo e altri (ecco perché sono evidenziati in verde). Sono usate come posizioni condivise per i file temporanei.

Con questi permessi, chiunque dovrebbe, teoricamente, essere in grado di fare qualsiasi cosa. Tuttavia, il bit adesivo li sovrascrive, e nessuno può cancellare un file che non gli appartiene.

Ricordi

Quella che segue è una rapida lista di controllo di ciò che abbiamo coperto sopra per riferimento futuro:

• SUID funziona solo sui file.
• È possibile applicare SGID a directory e file.
• Puoi applicare il bit adesivo solo alle directory.
• Se gli indicatori “s“, “g“, o “t” appaiono in maiuscolo, il bit eseguibile (x) non è stato impostato.