03/29/2024

Cum să utilizați SUID, SGID și Sticky Bits pe Linux

SUID, SGID și Sticky Bits sunt permisiuni speciale puternice pe care le puteți seta pentru executabile și directoare pe Linux. Vom împărtăși beneficiile și potențialele capcane ale utilizării acestora.

Sunt deja în uz

Construirea securității într-un sistem de operare multiutilizator prezintă mai multe dileme. Luați, de exemplu, conceptul (aparent) de bază al parolelor. Toate trebuie să fie stocate, astfel încât de fiecare dată când cineva se conectează, sistemul poate compara parola pe care o introduce cu copia stocată. Evident, deoarece parolele sunt cheile regatului, ele trebuie protejate.

Pe Linux, parolele stocate sunt protejate în două moduri: sunt criptate și numai cineva cu privilegii de root poate accesa fișierul care conține parolele. Ar putea suna bine, dar prezintă o dilemă: dacă numai persoanele cu privilegii de root pot accesa parolele stocate, cum își schimbă parolele cei care nu au acest acces?

Creșterea statutului dvs

De obicei, comenzile și programele Linux rulează cu același set de permisiuni ca și persoana care lansează programul. Când root rulează comanda passwd pentru a schimba o parolă, rulează cu permisiunile root. Aceasta înseamnă că comanda passwd poate accesa liber parolele stocate în fișierul /etc/shadow.

Ceea ce ar fi ideal este o schemă în care oricine din sistem ar putea lansa programul passwd, dar ca programul passwd să păstreze privilegiile ridicate ale root. Acest lucru ar permite oricui să-și schimbe propria parolă.

Scenariul de mai sus este exact ceea ce face bitul Set User ID (SUID). Aceasta rulează programe și comenzi cu permisiunile proprietarului fișierului, mai degrabă decât cu permisiunile persoanei care lansează programul.

Creșteți statutul programului

Există totuși o altă dilemă. Persoana trebuie să fie împiedicată să se amestece cu parola altcuiva. Linux încorporează schema SUID care îi permite să ruleze aplicații cu un set de permisiuni împrumutate temporar, dar aceasta este doar jumătate din povestea de securitate.

Mecanismul de control care împiedică pe cineva să lucreze cu parola altei persoane este conținut în programul passwd, nu în sistemul de operare și schema SUID.

Programele care rulează cu privilegii ridicate pot prezenta riscuri de securitate dacă nu sunt create cu o mentalitate de „securitate prin proiectare”. Asta înseamnă că securitatea este primul lucru pe care îl iei în considerare și apoi te bazezi pe asta. Nu vă scrieți programul și apoi încercați să-i dați un strat de securitate după aceea.

Cel mai mare avantaj al software-ului open source este te poți uita singur la codul sursă sau consultați evaluări de încredere ale acestuia. În codul sursă pentru programul passwd, există verificări, astfel încât să puteți vedea dacă persoana care rulează programul este root. Sunt permise diferite capacități dacă cineva este root (sau cineva care folosește sudo).

  Cum să faci terminalul Linux ușor de utilizat cu ColorLS

Acest este codul care detectează dacă cineva este root.

Un fragment de cod sursă din

Următorul este un exemplu în care acest lucru este luat în considerare. Deoarece root poate schimba orice parolă, programul nu trebuie să se deranjeze cu verificările pe care le efectuează de obicei pentru a vedea ce parole are permisiunea de a schimba persoana. Deci, pentru root, ea omite acele verificări și iese din funcția de verificare.

Un fragment de cod sursă din

Cu comenzile și utilitățile de bază Linux, puteți fi sigur că au securitate integrată în ele și că codul a fost revizuit de multe ori. Desigur, există întotdeauna amenințarea unor exploit-uri încă necunoscute. Cu toate acestea, patch-urile sau actualizările apar rapid pentru a contracara orice vulnerabilități nou identificate.

Este un software terță parte – în special orice care nu este open-source – trebuie să fii extrem de atent când folosești SUID. Nu spunem să nu o faceți, dar, dacă o faceți, doriți să vă asigurați că nu vă va expune sistemul la riscuri. Nu doriți să ridicați privilegiile unui program care nu se va auto-guverna corect în sine și persoana care îl rulează.

Comenzi Linux care folosesc SUID

Următoarele sunt câteva dintre comenzile Linux care folosesc bitul SUID pentru a oferi comenzii privilegii ridicate atunci când sunt executate de un utilizator obișnuit:

ls -l /bin/su
ls -l /bin/ping
ls -l /bin/mount
ls -l /bin/umount
ls -l /usr/bin/passwd

Rețineți că numele fișierelor sunt evidențiate cu roșu, ceea ce indică că bitul SUID este setat.

Permisiunile pentru un fișier sau director sunt de obicei reprezentate de trei grupuri de trei caractere: rwx. Acestea înseamnă citire, scriere și execuție. Dacă scrisorile sunt prezente, acea permisiune a fost acordată. Dacă este prezentă o cratimă (-) în loc de o literă, totuși, acea permisiune nu a fost acordată.

Există trei grupuri de aceste permisiuni (de la stânga la dreapta): cele pentru proprietarul fișierului, pentru membrii grupului fișierului și pentru alții. Când bitul SUID este setat pe un fișier, un „s” reprezintă permisiunea de execuție a proprietarului.

Dacă bitul SUID este setat pe un fișier care nu are capabilități executabile, un „S” majuscule indică acest lucru.

Vom arunca o privire la un exemplu. Utilizatorul obișnuit dave introduce comanda passwd:

passwd

The

Comanda passwd îi solicită lui Dave noua lui parolă. Putem folosi comanda ps pentru a vedea detaliile proceselor care rulează.

Vom folosi ps cu grep într-o fereastră de terminal diferită și căutați procesul passwd. Vom folosi, de asemenea, opțiunile -e (fiecare proces) și -f (format complet) cu ps.

Introducem următoarea comandă:

ps -e -f | grep passwd

The

Sunt raportate două linii, dintre care a doua este procesul grep care caută comenzi cu șirul „passwd” în ele. Este prima linie care ne interesează, totuși, pentru că aceasta este cea pentru procesul passwd lansat de Dave.

  Cum să joci Deadcore pe Linux

Putem vedea că procesul passwd rulează la fel ca dacă root l-ar fi lansat.

Setarea bitului SUID

Este ușor să schimbați bitul SUID cu chmod. Modul simbolic u+s setează bitul SUID, iar modul simbolic us șterge bitul SUID.

Pentru a ilustra unele dintre conceptele bitului SUID, am creat un mic program numit htg. Se află în directorul rădăcină al utilizatorului dave și nu are setat bitul SUID. Când este executat, afișează ID-urile de utilizator reale și efective (UID).

Realul UID aparține persoanei care a lansat programul. ID-ul efectiv este contul prin care programul se comportă ca și cum ar fi fost lansat.

Introducem următoarele:

ls -lh htg
./htg

The

Când rulăm copia locală a programului, vedem că ID-urile reale și efective sunt setate la dave. Deci, se comportă exact așa cum ar trebui un program normal.

Să-l copiem în directorul /usr/local/bin pentru ca alții să-l poată folosi.

Introducem următoarele, folosind chmod pentru a seta bitul SUID și apoi verificăm dacă a fost setat:

sudo cp htg /usr/local/bin
sudo chmod u+s /usr/local/bin/htg
ls -hl /usr/local/bin/htg

The

Deci, programul este copiat și bitul SUID este setat. O vom rula din nou, dar de data aceasta vom rula copia în folderul /usr/local/bin:

htg

The

Chiar dacă dave a lansat programul, ID-ul efectiv este setat la utilizatorul root. Deci, dacă Mary lansează programul, se întâmplă același lucru, așa cum se arată mai jos:

htg

The

ID-ul real este Mary, iar ID-ul efectiv este root. Programul rulează cu permisiunile utilizatorului root.

Bitul SGID

Bitul Set Group ID (SGID) este foarte asemănător cu bitul SUID. Când bitul SGID este setat pe un fișier executabil, grupul efectiv este setat la grupul fișierului. Procesul rulează cu permisiunile membrilor grupului fișierului, mai degrabă decât cu permisiunile persoanei care l-a lansat.

Ne-am ajustat programul htg, astfel încât să arate și grupul eficient. Vom schimba grupul programului htg pentru a fi grupul implicit al utilizatorului mary, mary. Vom folosi, de asemenea, modurile simbolice us și g+s cu chown pentru a elimina bitul SUID și a seta SGID.

Pentru a face acest lucru, introducem următoarele:

sudo chown root:mary /usr/local/bin/htg
sudo chmod u-s,g+s /usr/local/bin/htg
ls -lh /usr/local/bin/htg

The

Puteți vedea bitul SGID notat cu „s” în permisiunile de grup. De asemenea, rețineți că grupul este setat la Mary și numele fișierului este acum evidențiat cu galben.

Înainte de a rula programul, să stabilim căror grupuri aparțin Dave și Mary. Vom folosi comanda id cu opțiunea -G (grupuri), pentru a tipări toate ID-urile grupului. Apoi, vom rula programul htg ca Dave.

Introducem următoarele comenzi:

id -G dave
id -G mary
htg

The

ID-ul grupului implicit pentru mary este 1001, iar grupul efectiv al programului htg este 1001. Deci, deși a fost lansat de dave, rulează cu permisiunile membrilor din grupul mary. Este la fel ca și cum Dave s-ar fi alăturat grupului Mary.

Să aplicăm bitul SGID unui director. Mai întâi, vom crea un director numit „work”, apoi vom schimba grupul în „geek”. Apoi vom seta bitul SGID în director.

  Cum să dezarhivați fișierele TarGZ în Linux

Când folosim ls pentru a verifica setările directorului, vom folosi și opțiunea -d (director) astfel încât să vedem detaliile directorului, nu conținutul acestuia.

Introducem următoarele comenzi:

sudo mkdir work
sudo chown dave:geek work
sudo chmod g+s work
ls -lh -d work

The

Bitul SGID și grupul „geek” sunt setate. Acestea vor afecta orice elemente create în directorul de lucru.

Introducem următoarele pentru a intra în directorul de lucru, creăm un director numit „demo” și verificăm proprietățile acestuia:

cd work
mkdir demo
ls -lh -d demo

The

Bitul SGID și grupul „geek” sunt aplicate automat directorului „demo”.

Să introducem următoarele pentru a crea un fișier cu atingere comandă și verifică proprietățile acesteia:

touch useful.sh
ls -lh useful.sh

The

Grupul noului fișier este setat automat la „geek”.

The Sticky Bit

Bitul lipicios își trage numele de la scopul său istoric. Când se setează pe un executabil, sistemul de operare a semnalat faptul că porțiunile de text ale executabilului ar trebui să fie reținute în schimb, făcând reutilizarea lor mai rapidă. Pe Linux, sticky bit afectează doar un director – setarea lui într-un fișier nu ar avea sens.

Când setați sticky bit pe un director, oamenii pot șterge numai fișierele care le aparțin din acel director. Ei nu pot șterge fișierele care aparțin altcuiva, indiferent de combinația de permisiuni ale fișierelor setate pentru fișiere.

Acest lucru vă permite să creați un director pe care toată lumea – și procesele pe care le lansează – să-l poată folosi ca stocare de fișiere partajată. Fișierele sunt protejate pentru că, din nou, nimeni nu poate șterge fișierele altcuiva.

Să creăm un director numit „partajat”. Vom folosi modul simbolic o+t cu chmod pentru a seta sticky bit pe acel director. Ne vom uita apoi la permisiunile din acel director, precum și la directoarele /tmp și /var/tmp.

Introducem următoarele comenzi:

mkdir shared
sudo chmod o+t shared
ls -lh -d shared
ls -lh -d /tmp
ls -lh -d /var/tmp

The

Dacă sticky bit este setat, bitul executabil al „altelor” seturi de permisiuni de fișier este setat la „t”. Numele fișierului este, de asemenea, evidențiat în albastru.

Dosarele /tmp și /var/tmp sunt două exemple de directoare care au toate permisiunile de fișiere setate pentru proprietar, grup și altele (de aceea sunt evidențiate cu verde). Sunt folosite ca locații partajate pentru fișierele temporare.

Cu aceste permisiuni, oricine ar trebui, teoretic, să poată face orice. Cu toate acestea, sticky bit le suprascrie și nimeni nu poate șterge un fișier care nu îi aparține.

Mementouri

Următoarea este o listă de verificare rapidă a ceea ce am acoperit mai sus pentru referințe viitoare:

SUID funcționează numai pe fișiere.
Puteți aplica SGID directoarelor și fișierelor.
Puteți aplica doar sticky bit în directoare.
Dacă indicatorii „s“, „g“ sau „t“ apar cu majuscule, bitul executabil (x) nu a fost setat.