Permisiunile fișierelor în Linux

Bună ziua tuturor. Ne integrăm activ în muncă și deja în ianuarie pregătim multe lansări puternice. Printre altele, a fost anunțat începerea unui nou curs foarte apreciat. „Administrator Linux”. În preajma lansării, împărtășim tradițional traducerea unui material util.

Permisiunile fișierelor în Linux

Permisiunile de fișiere oferă o alternativă sigură la fișierele executabile SUID, dar pot părea puțin confuze la prima vedere.


Toți știm că fișierele binare SUID sunt o soluție proastă din punct de vedere al securității. Din fericire, dacă aplicația dumneavoastră necesită privilegii limitate, există o modalitate mai eficientă, numită permisiuni de fișiere.

Îți voi economisi timpul, dacă dorești să eviți citirea detaliată a articolului de mai sus: în esență, permisiunile de fișiere permit proceselor care sunt lansate sub identitatea utilizatorului root și, prin urmare, au dreptul de a face orice, să păstreze anumite capacități, limitate la această listă, atunci când renunță la privilegii și sunt lansate ca utilizator fără privilegii. Asta înseamnă că, dacă un atacator reușește să compromită un proces printr-o suprascriere a buffer-ului sau prin altă vulnerabilitate, el nu va putea beneficia decât de anumite privilegii minime, de care procesul are cu adevărat nevoie.

Permisiunile sunt excelente pentru serviciile care de obicei sunt lansate sub identitatea utilizatorului root, dar ce zici de utilitarele de linie de comandă? Din fericire, acest lucru este de asemenea susținut, cu condiția ca tu să ai instalate utilitarele corecte. Dacă folosești Ubuntu, de exemplu, vei avea nevoie de pachetul libcap2-bin. De asemenea, va trebui să rulezi un kernel nu arhaic (începând cu versiunea 2.6.24).

Aceste funcții permit legarea permisiunilor la fișierele executabile în mod similar cu configurarea bitului SUID, dar doar pentru un anumit set de permisiuni. Utilitarul setcap este folosit pentru a adăuga și elimina permisiuni dintr-un fișier.

Primul pas este să alegi permisiunile de care ai nevoie. Pentru acest articol, presupun că există un instrument de diagnosticare a rețelei, numit tracewalk, care ar trebui să fie capabil să folosească sockets neprocesate. În mod obișnuit, pentru aceasta, aplicația trebuie să fie executată sub identitatea utilizatorului root, dar când te uiți la lista se dovede că este necesar doar un permisiune CAP_NET_RAW.

Presupunând că te afli în directorul unde se află fișierul binar tracewalk, poți adăuga această permisiune astfel:

sudo setcap cap_net_raw=eip tracewalk

Între timp, poți ignora sufixul =eip pentru permisiune, îți voi explica în câteva momente. Observă că numele permisiunii este scris cu litere mici. Acum poți verifica dacă ai configurat corect permisiunile folosind:

setcap -v cap_new_raw=eip tracewalk

Sau poți lista toate permisiunile setate pentru acest fișier executabil:

getcap tracewalk

Pentru referință, poți elimina toate permisiunile din fișierul executabil folosind:

setcap -r tracewalk

În acest moment, ar trebui să poți rula fișierul executabil ca utilizator neprivilegiat, și acesta ar trebui să aibă capacitatea de a lucra cu socket-uri brute, dar să nu aibă alte privilegii care le deține utilizatorul root.

Deci, ce înseamnă acest sufix ciudat =eip? Здесь потребуется толика понимания природы разрешений. Каждый процесс имеет три набора разрешений — efectiv, moștenibil și permis (effective, inheritable și permitted):

  • Permisiunile Efective (Effective) sunt cele care determină ceea ce procesul poate face efectiv. De exemplu, nu poate lucra cu socket-uri brute dacă CAP_NET_RAW nu se află în setul efectiv.
  • Permisiunile Permisibile (Permitted) sunt cele care este permis să le aibă procesul, dacă le solicită prin apelul corespunzător. Acestea nu permit procesului să facă efectiv nimic, decât dacă a fost specific creat pentru a solicita permisiunea specificată. Acest lucru permite scrierea proceselor pentru a adăuga permisiuni extrem de importante în setul efectiv doar pentru perioada în care acestea sunt efectiv necesare.
  • Permisiunile Moștenibile (Inheritable) sunt cele care pot fi moștenite în setul disponibil al procesului copil. În timpul operației fork() sau clone() procesului copil i se oferă întotdeauna o copie a permisiunilor procesului părinte, deoarece în acel moment acesta încă execută același fișier executabil. Setul moștenit este utilizat atunci când exec() (sau echivalentul) este apelat pentru a înlocui fișierul executabil cu altul. În acest stadiu, setul accesibil al procesului este mascat de setul moștenit pentru a obține setul accesibil care va fi folosit pentru noul proces.

Astfel, utilitarul setcap ne permite să adăugăm permisiunile celor trei seturi independent pentru acest fișier executabil. Rețineți că valoarea grupurilor este interpretată puțin diferit pentru permisiunile fișierelor:

  • Linii de alimentare duble disponibile 2×220 V permisiunile fișierelor sunt cele care sunt întotdeauna disponibile pentru fișierul executabil, chiar dacă procesul părinte care l-a chemat nu le avea. În trecut, se numeau «permisiuni forțate».
  • Moștenite permisiunile fișierelor definesc o mască suplimentară, care poate fi folosită pentru a elimina permisiunile din setul procesului apelant. Acestea se aplică în plus față de setul moștenit al procesului apelant, deci permisiunea este moștenită doar dacă există în ambele seturi.
  • Efective permisiunile fișierelor reprezintă de fapt un singur bit, nu un set, iar dacă este setat, înseamnă că întregul set disponibil este de asemenea copiat în setul efectiv al noului proces. Acesta poate fi folosit pentru a adăuga permisiuni la procese care nu au fost scrise special pentru a le solicita. Deoarece este un singur bit, dacă îl setați pentru o permisiune, acesta trebuie să fie setat pentru toate permisiunile. Puteți să vă gândiți la el ca la un bit de moștenire, deoarece este folosit pentru a permite utilizarea permisiunilor pentru aplicații care nu le susțin.

Când se specifică permisiunile prin setcap trei litere e, i și p se referă la efectiv, moștenit și disponibil seturi, respectiv. Așadar, specificația anterioară:

sudo setcap cap_net_raw=eip tracewalk

… indică faptul că permisiunea CAP_NET_RAW ar trebui să fie adăugată la seturile disponibile și moștenite și că bitul efectiv ar trebui să fie de asemenea setat. Aceasta va înlocui orice permisiuni setate anterior în fișier. Pentru a seta mai multe permisiuni simultan, folosiți o listă separată prin virgulă:

sudo setcap cap_net_admin,cap_net_raw=eip tracewalk

Ghid pentru permisiuni discută toate acestea mai detaliat, dar, sper, acest post a demistificat puțin ceea ce se întâmplă. Rămâne doar să menționăm câteva avertismente și trucuri.

În primul rând, capacitățile fișierelor nu funcționează cu link-uri simbolice — trebuie să le aplicați fișierului binar în sine (adică țintei link-ului simbolic).

În al doilea rând, ele nu funcționează cu scripturi interpretate. De exemplu, dacă aveți un script Python căruia doriți să-i atribuiți permisiuni, trebuie să le atribuiți direct interpretului Python. Este evident că aceasta reprezintă o potențială problemă de securitate, deoarece toate scripturile executate cu acest interpret vor avea permisiunile specificate, deși este totuși considerabil mai bine decât să folosiți SUID. Cea mai comună soluție pare să fie scrierea unui fișier executabil separat în C sau un echivalent, care poate efectua operațiile necesare și a-l apela din script. Acest lucru este similar cu abordarea folosită de Wireshark, care utilizează un fișier binar. /usr/bin/dumpcap pentru a efectua operațiuni privilegiate:

$ getcap /usr/bin/dumpcap 
/usr/bin/dumpcap = cap_net_admin,cap_net_raw+eip

În al treilea rând, permisiunile fișierelor sunt dezactivate dacă utilizați o variabilă de mediu LD_LIBRARY_PATH din motive de securitate evidente(1). Același lucru se aplică și la LD_PRELOAD, în măsura în care știu.

1. Deoarece un atacator poate, evident, să substituie una dintre bibliotecile standard și să folosească LD_LIBRARY_PATH, pentru a face biblioteca sa să fie apelată înaintea celei de sistem, având astfel propriul cod arbitrar executat cu aceleași privilegii ca aplicația apelantă.

Asta este tot. Detalii despre programul cursului vor putea fi găsite la webinarul care va avea loc pe 24 ianuarie.

Sursa: habr.com

Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS 🔥 Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS | ProHoster