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

• Dave McKay

  @TheGurkha

• Februarie 26, 2020, 8:00am EDT

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 lor.

Ele sunt deja folosite

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 să poată compara parola pe care o tastează cu copia stocată. Evident, cum parolele sunt cheile regatului, ele trebuie să fie protejate.

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

Elevarea statutului dumneavoastră

În mod normal, comenzile și programele Linux rulează cu același set de permisiuni ca și persoana care lansează programul. Când root execută comanda passwd pentru a schimba o parolă, aceasta se execută cu permisiunile lui 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 în care programul passwd să păstreze privilegiile ridicate ale lui root. Acest lucru ar împuternici pe oricine să își schimbe propria parolă.

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

Elevați statutul programului

Există însă 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 securității.

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 în schema SUID.

Programele care rulează cu privilegii ridicate pot prezenta riscuri de securitate dacă nu sunt create cu o mentalitate de „securitate prin proiectare”. Aceasta înseamnă că securitatea este primul lucru pe care îl luați în considerare, iar apoi construiți pe această bază. 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 cu sursă deschisă este că puteți să vă uitați singur la codul sursă sau să vă referiți la recenzii de încredere ale acestuia de către colegi. În codul sursă pentru programul passwd, există verificări, astfel încât puteți vedea dacă persoana care rulează programul este root. Diferite capabilități sunt permise dacă cineva este root (sau cineva care folosește sudo).

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

Cel de mai jos este un exemplu în care se ține cont de acest lucru. 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 respectivă. Astfel, pentru root, acesta sare peste aceste verificări și iese din funcția de verificare.

Cu comenzile și utilitarele de bază ale Linux, puteți fi siguri că au securitatea încorporată în ele și că codul a fost revizuit de mai 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.

Sunt programe de la terți – în special cele care nu sunt open-source – cu care trebuie să fiți extrem de atenți când folosiți SUID. Nu spunem să nu o faceți, dar, dacă o faceți, trebuie 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 autoguverna în mod corect pe sine și pe persoana care îl execută.

Comande Linux care folosesc SUID

Cele de mai jos sunt câteva dintre comenzile Linux care folosesc bitul SUID pentru a conferi comenzii privilegii ridicate atunci când este rulată 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ă faptul că bitul SUID este setat.

Autorizațiile unui fișier sau director sunt reprezentate de obicei prin trei grupuri de trei caractere: rwx. Acestea reprezintă citire, scriere și execuție. Dacă literele sunt prezente, permisiunea respectivă a fost acordată. Totuși, dacă este prezentă o cratimă (-) în loc de o literă, acea permisiune nu a fost acordată.

Există trei grupe ale acestor permisiuni (de la stânga la dreapta): cele pentru proprietarul fișierului, pentru membrii grupului fișierului și pentru alții. Atunci 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 capacități de execuție, un „S” majusculă denotă acest lucru.

Ne vom uita la un exemplu. Utilizatorul obișnuit dave tastează comanda passwd:

passwd

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

Vom folosi ps cu grep într-o altă fereastră de terminal și vom căuta procesul passwd. Vom folosi, de asemenea, opțiunile -e (every process) și -f (full-format) cu ps.

Trim următoarea comandă:

ps -e -f | grep passwd

Sunt raportate două linii, dintre care a doua este procesul grep care caută comenzi cu șirul „passwd” în ele. Totuși, prima linie este cea care ne interesează, pentru că este cea a procesului passwd pe care l-a lansat dave.

Veziem că procesul passwd rulează la fel ca și cum l-ar fi lansat root.

Setting the SUID Bit

Este ușor de schimbat bitul SUID cu chmod. Modul simbolic u+s setează bitul SUID, iar modul simbolic u-s șterge bitul SUID.

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

UID-ul real aparține persoanei care a lansat programul. ID-ul efectiv este contul cu care se comportă programul ca și cum ar fi fost lansat de către acesta.

Tipăm următoarele:

ls -lh htg

./htg

Când executăm copia locală a programului, vedem că ID-ul real și cel efectiv sunt ambele setate la dave. Deci, se comportă exact așa cum ar trebui să se comporte un program normal.

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

Tectăm următoarele, folosind chmod pentru a seta bitul SUID, 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

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

htg

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

htg

Identificarea reală este mary, iar cea efectivă este root. Programul rulează cu permisiunile utilizatorului root.

RELATED: Cum se utilizează comanda chmod pe Linux

Bit-ul SGID

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

Am modificat programul nostru htg astfel încât să arate și grupul efectiv. Vom schimba grupul programului htg pentru a fi grupul implicit al utilizatorului mary, mary. De asemenea, vom folosi modurile simbolice u-s și g+s cu chown pentru a elimina bitul SUID și a seta SGID.

Pentru a face acest lucru, vom tasta 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

Puteți vedea bitul SGID denotat prin „s” în permisiunile de grup. De asemenea, observați că grupul este setat la mary, iar numele fișierului este acum evidențiat în galben.

Înainte de a rula programul, să stabilim din ce grupuri fac parte dave și mary. Vom folosi comanda id cu opțiunea -G (groups), pentru a imprima toate ID-urile grupurilor. Apoi, vom rula programul htg ca dave.

Tăipăm următoarele comenzi:

id -G dave

id -G mary

htg

ID-ul grupului implicit pentru mary este 1001, iar grupul efectiv al programului htg este 1001. Deci, deși a fost lansat de dave, acesta 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 la un director. Mai întâi, vom crea un director numit „work”, apoi îi vom schimba grupul în „geek”. Apoi vom seta bitul SGID pe director.

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.

Trim următoarele comenzi:

sudo mkdir work

sudo chown dave:geek work

sudo chmod g+s work

ls -lh -d work

Bit-ul SGID și grupul „geek” sunt setate. Acestea vor afecta orice element creat în cadrul directorului work.

Tăipăm următoarele pentru a intra în directorul work, a crea un director numit „demo” și a-i verifica proprietățile:

cd work

mkdir demo

ls -lh -d demo

Bit-ul SGID și grupul „geek” sunt aplicate automat directorului „demo”.

Să tastăm următoarele pentru a crea un fișier cu comanda touch și să-i verificăm proprietățile:

touch useful.sh

ls -lh useful.sh

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

RELATED: How to Use the chown Command on Linux

The Sticky Bit

Bit-ul lipicios își primește numele de la scopul său istoric. Atunci când este setat pe un executabil, acesta semnalează sistemului de operare că porțiunile de text ale executabilului ar trebui să fie păstrate în swap, ceea ce face ca reutilizarea lor să fie mai rapidă. Pe Linux, bitul lipicios afectează doar un director – stabilirea lui pe un fișier nu ar avea sens.

Când setați bitul lipicios pe un director, oamenii pot șterge doar fișierele care le aparțin din acel director. Ei nu pot șterge fișiere care aparțin altcuiva, indiferent de combinația de permisiuni de fișier setată pe fișiere.

Aceasta vă permite să creați un director pe care toată lumea – și procesele pe care le lansează – îl poate folosi ca stocare de fișiere partajate. Fișierele sunt protejate deoarece, din nou, nimeni nu poate șterge fișierele altcuiva.

Să creăm un director numit „shared”. Vom folosi modul simbolic o+t cu chmod pentru a seta bitul lipicios pe acel director. Ne vom uita apoi la permisiunile acelui director, precum și la cele ale directoarelor /tmp și /var/tmp.

Tăipăm următoarele comenzi:

mkdir shared

sudo chmod o+t shared

ls -lh -d shared

ls -lh -d /tmp

ls -lh -d /var/tmp

Dacă bitul lipicios este setat, bitul executabil din setul de permisiuni „other” al fișierelor este setat la „t”. Numele fișierului este, de asemenea, evidențiat în albastru.

Directoarele /tmp și /var/tmp sunt două exemple de directoare care au toate permisiunile de fișier setate pentru proprietar, grup și alții (de aceea sunt evidențiate în verde). Ele sunt folosite ca locații partajate pentru fișiere temporare.

Cu aceste permisiuni, oricine ar trebui, teoretic, să poată face orice. Cu toate acestea, bitul lipicios le anulează și nimeni nu poate șterge un fișier care nu-i aparține.

Remarcații

Cele ce urmează sunt o scurtă listă de verificare a ceea ce am acoperit mai sus, pentru referințe viitoare:

• SUID SUID funcționează numai pe fișiere.
• Puteți aplica SGID la directoare și fișiere.
• Puteți aplica bitul lipicios numai la directoare.
• Dacă indicatorii „s„, „g” sau „t” apar cu majuscule, bitul executabil (x) nu a fost setat.