SUD, SGID e Sticky Bits sono potenti permessi speciali che puoi impostare per eseguibili e directory in Linux. Condivideremo i vantaggi, e i possibili inconvenienti, usarli.
Sono già in uso
L'integrazione della sicurezza in un sistema operativo multiutente presenta diversi dilemmi. Prendi il concetto (apparentemente) password di base, come esempio. Tutto dovrebbe essere archiviato in modo che ogni volta che qualcuno effettua l'accesso, il sistema può confrontare la password digitata con la copia memorizzata. Apparentemente, poiché le password sono le chiavi del regno, deve essere protetto.
En Linux, le password memorizzate sono protette in due modi: sono crittografati e solo qualcuno con root
I privilegi possono entrare nel file contenente le password. Può suonare bene, ma presenta un dilemma: se solo le persone con root
i privilegi possono inserire password memorizzate, Come cambia la password chi non ha quell'accesso??
Elevare il tuo stato
Generalmente, I comandi e i programmi di Linux vengono eseguiti con lo stesso insieme di autorizzazioni della persona che avvia il programma. quando root
corri il passwd
comando per cambiare una password, corre con root
permessi di. Ciò significa che passwd
Il comando può inserire liberamente le password memorizzate nel /etc/shadow
procedimento.
Quello che sarebbe l'ideale è uno schema in cui chiunque nel sistema potrebbe avviare il passwd
Programma, ma avere il passwd
tenere programma root
privilegi elevati. Ciò consentirebbe a chiunque di modificare la propria password.
Lo scenario sopra è esattamente ciò che fa il bit Determina ID utente (SUID
) lo fa?. Quella eseguire programmi e comandi con i permessi del proprietario del file, invece dei permessi della persona che avvia il programma.
Stai alzando lo stato dello spettacolo
Nonostante questo, c'è un altro dilemma. Alla persona dovrebbe essere impedito di manomettere la password di qualcun altro. Linux incorpora il SUID
schema che consente di eseguire applicazioni con una serie di autorizzazioni temporaneamente prese in prestito, ma questa è solo metà della storia della sicurezza.
Il meccanismo di controllo che impedisce a qualcuno di lavorare con la password di qualcun altro è incluso nel passwd
Programma, non lo schema OS e SUID.
I programmi eseguiti con privilegi elevati possono presentare rischi per la sicurezza se non vengono creati con una mentalità di sicurezza. “sicurezza in base alla progettazione”. Ciò significa che la sicurezza viene prima di tutto e si basa su quella prima.. Non scrivere il tuo programma e poi provare a dargli un livello di sicurezza.
Il più grande vantaggio del software open source è puoi guardare tu stesso il codice sorgente o fare riferimento a peer review affidabili. Nel codice sorgente del passwd
Programma, ci sono controlli, così puoi vedere se la persona che esegue il programma è root
. Diverse capacità sono possibili se qualcuno root
(o qualcuno che usa sudo
).
Questo è il codice che rileva se qualcuno è root
.
Quello che segue è un esempio che tiene conto. Perché root
puoi cambiare qualsiasi password, il programma non deve preoccuparsi dei controlli che esegue regolarmente per vedere quali password la persona ha il permesso di cambiare. Quindi, per root
, Quello salta quei controlli ed esci dalla funzione di controllo.
Con i principali comandi e utilità di Linux, puoi essere sicuro che hanno una sicurezza integrata e il codice è stato controllato spesso. In ogni caso, c'è sempre la minaccia di exploit ancora sconosciuti. Nonostante questo, patch o aggiornamenti vengono visualizzati rapidamente per contrastare eventuali vulnerabilità identificate di recente.
È un software di terze parti, soprattutto se non open source, dovresti stare molto attento quando usi SUID
insieme a. Non stiamo dicendo di no, ma, se lo fa, devi assicurarti di non esporre il tuo sistema a rischi. Non vuoi elevare i privilegi di un programma che non autogovernerà correttamente se stesso e la persona che lo esegue.
Comandi Linux che usano SUID
Di seguito sono riportati alcuni dei comandi Linux che utilizzano il bit SUID per concedere privilegi elevati al comando quando eseguito da un utente normale:
ls -l / bin / su
ls -l /bin/ping
ls -l /bin/mount
ls -l /bin/smontare
ls -l /usr/bin/passwd
Nota che i nomi dei file sono evidenziati in rosso, indicando che il bit SUID è impostato.
I permessi su un file o una directory sono generalmente rappresentati da tre gruppi di tre caratteri: rwx. Questi significano leggere, scrittura ed esecuzione. Se le carte sono presenti, che il permesso è stato concesso. Se uno script (-
) invece di una lettera è presente, nonostante questo, quel permesso non è stato dato.
Esistono tre gruppi di queste autorizzazioni (da sinistra a destra): per il proprietario del file, per i membri del gruppo archivio e per gli altri. Quando il SUID
bit è impostato su un file, un “S” rappresenta il permesso di esecuzione del proprietario.
Se lui SUID
bit è impostato su un file che non ha capacità eseguibili, un “S” indica la maiuscola.
Vedremo un esempio. Utente regolare dave
Scrivi la passwd
comando:
passwd
il passwd
prompt dei comandi dave
per la tua nuova password. Possiamo usare il ps
comando per visualizzare i dettagli dei processi in esecuzione.
noi useremo ps
insieme a grep
in un'altra finestra di terminale e cerca il passwd
processi. Useremo anche il -e
(ogni procedura) e -f
(formato completo) opzioni con ps
.
Scriviamo il seguente comando:
ps -e -f | grep password
Sono riportate due righe, il secondo dei quali è il grep
procedura di ricerca dei comandi con la stringa “passwd” Non è necessario aggiungere l'estensione. Nonostante questo, è la prima riga che ci interessa, perché è quello del passwd
processi dave
buttato fuori.
Possiamo vedere il passwd
La procedura funziona come se root
l'avevo buttato.
Impostazione bit SUID
È facile cambiare il SUID
un po' con chmod
. il u+s
la modalità simbolica imposta il SUID
piccolo e il u-s
la modalità simbolica cancella il SUID
poco.
Per illustrare alcuni concetti sui bit SUID, abbiamo creato un piccolo programma chiamato htg
. Si trova nella directory principale del dave
Nome utente, e non ha il SUID
bit impostato. Quando corri, mostra gli ID utente effettivi ed effettivi (UID).
Il vero UID appartiene alla persona che ha lanciato il programma. L'ID effettivo è l'account con cui il programma si comporta come se lo avesse avviato.
Scriviamo quanto segue:
ls -lh htg
./htg
Quando eseguiamo la copia locale del programma, vediamo che gli ID reali ed effettivi sono configurati in dave
. Quindi, si sta comportando come dovrebbe un normale programma.
Copiamo nel /usr/local/bin
directory che altri possono usare.
Scriviamo quanto segue, usando chmod
per configurare il SUID
po, e successivamente verificare che sia stato configurato:
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 viene impostato il bit SUID. Lo eseguiremo di nuovo, ma questa volta eseguiremo la copia nel /usr/local/bin
file:
htg
Sebbene dave
avviato il programma, l'ID effettivo è impostato in root
Nome utente. Quindi sì mary
avvia il programma, succede lo stesso, come mostrato di seguito:
htg
L'ID effettivo è mary
, e l'ID effettivo è root
. Il programma viene eseguito con i permessi dell'utente root.
IMPARENTATO: Come usare il comando chmod in Linux
El bit SGID
L'ID di gruppo impostato (SGID
) bit è molto simile a SUID
poco. Quando il SGID
bit è impostato su un file eseguibile, il gruppo effettivo è impostato sul gruppo di file. La procedura viene eseguita con i permessi dei membri del gruppo del file, invece dei permessi della persona che l'ha avviato.
Adeguiamo il nostro htg
programma per mostrare anche il gruppo effettivo. Cambieremo il gruppo da htg
programma per essere un utente mary
gruppo predefinito, mary
. Useremo anche il u-s
e g+s
modi simbolici con chown
per rimuovere il SUID
bit e determinare il SGID
.
Per farlo, scriviamo quanto segue:
sudo chown root:maria /usr/local/bin/htg
sudo chmod u-s,g+s /usr/local/bin/htg
ls -lh /usr/local/bin/htg
Puoi vedere il SGID
bit indicato dal “S” nelle autorizzazioni di gruppo. Allo stesso tempo, si noti che il gruppo è configurato per mary
e il nome del file è ora evidenziato in giallo.
Prima di eseguire il programma, stabiliamo quali gruppi dave
e mary
appartenente a. Useremo il id
comando con il -G
opzione (gruppi), per stampare tutti gli ID di gruppo. Successivamente, eseguiremo il htg
programma come dave
.
Scriviamo i seguenti comandi:
id -G dave
id -G mary
htg
L'ID di gruppo predefinito per mary
è 1001, e il gruppo effettivo di htg
il programma è 1001. Quindi, anche quando è stato rilasciato da dave
, funziona con i permessi dei membri nel mary
gruppo. È come se dave
si era unito al mary
gruppo.
Applichiamo il SGID
bit in una directory. Primo, creeremo una directory chiamata “lavoro” e in seguito cambieremo il tuo gruppo in “La virgoletta singola o l'apostrofo della parola”. Successivamente configureremo il SGID
bit nella directory.
Quando usiamo ls
per controllare la configurazione della directory, useremo anche il -d
(directory) così possiamo vedere i dettagli della directory, non il suo contenuto.
Scriviamo i seguenti comandi:
sudo mkdir funziona
sudo chown dave:lavoro geek
sudo chmod g+s funziona
ls -lh -d lavoro
il SGID
Bit e gruppo sono impostati “La virgoletta singola o l'apostrofo della parola”. Ciò influenzerà gli elementi creati all'interno del work
directory.
Scriviamo quanto segue per inserire il work
directory, creare una directory chiamata “demo” e verificarne le proprietà:
lavoro su cd
demo mkdir
ls -lh -d demo
il SGID
bit e gruppo “La virgoletta singola o l'apostrofo della parola” vengono applicati automaticamente alla directory “demo”.
Scriviamo quanto segue per creare un file con il touch
comando e controlla le sue proprietà:
tocco utile.sh
ls -lh utile.sh
Il gruppo del nuovo file viene impostato automaticamente su “La virgoletta singola o l'apostrofo della parola”.
IMPARENTATO: Come usare il comando chown in Linux
Il bit appiccicoso
Lo sticky bit prende il nome dal suo obiettivo storico. Quando configurato in un eseguibile, istruisce il sistema operativo che le parti di testo dell'eseguibile devono essere mantenute in cambio, che ne velocizza il riutilizzo. En Linux, il bit appiccicoso interessa solo una directory; impostarlo su un file non avrebbe senso.
Quando imposti il bit di colla in una directory, le persone possono rimuovere solo i file che appartengono a loro all'interno di quella directory. Non possono rimuovere file che appartengono a qualcun altro, indipendentemente dalla combinazione di permessi dei file impostata sui file.
Ciò consente di creare una directory che tutti, e i processi che iniziano, può essere utilizzato come archivio di file condiviso. I file sono protetti perché, ancora, nessuno può cancellare i file di qualcun altro.
Creiamo una directory chiamata “condivisa”. Useremo il o+t
modalità simbolica con chmod
per determinare lo sticky bit in quella directory. Più tardi vedremo i permessi in quella directory, così come il /tmp
e /var/tmp
directory.
Scriviamo i seguenti comandi:
mkdir condiviso
sudo chmod o+t shared
ls -lh -d condiviso
ls -lh -d / tmp
ls -lh -d / var / tmp
Se lo sticky bit è impostato, il bit eseguibile di “Altro” il set di autorizzazioni file è impostato su “T”. Anche il nome del file è evidenziato in blu.
il /tmp
e /var/tmp
Le cartelle sono due esempi di directory che hanno tutti i permessi di file impostati per il proprietario, il gruppo e gli altri (ecco perché sono evidenziati in verde). Sono usati come posizioni condivise per i file temporanei.
Con quei permessi, chiunque dovrebbe, teoricamente, poter fare qualsiasi cosa. Nonostante questo, sticky bit li sovrascrive e nessuno può rimuovere un file che non gli appartiene.
Promemoria
Il prossimo è un rapido elenco di controllo di ciò che abbiamo trattato in precedenza per riferimento futuro.:
SUID
funziona solo sui file.- Può applicare
SGID
a directory e file. - Puoi applicare lo sticky bit solo alle directory.
- Se lui “
s
“,”g
“, oh “t
Gli "indicatori appaiono in maiuscolo", il bit eseguibile (x
) Non configurato.