Pe multe sisteme Linux, permisiunile speciale SUID și SGID sunt normale și uneori necesare. Problema apare când aceste fișiere rămân neverificate luni la rând. Un binar cu astfel de permisiuni rulează cu drepturile proprietarului sau ale grupului său, nu doar cu drepturile utilizatorului care îl pornește. Asta înseamnă că o configurare greșită, un fișier apărut în locul nepotrivit sau un program vulnerabil pot mări rapid suprafața de risc pe un server ori pe o stație de lucru.
Pe scurt, SUID vine de la set user ID, iar SGID de la set group ID. În practică, acești biți speciali sunt folosiți pentru programe care au nevoie de privilegii suplimentare pentru o acțiune strictă, cum ar fi schimbarea parolei sau accesul controlat la anumite resurse de sistem. Tocmai de aceea nu orice fișier cu SUID sau SGID este suspect. Important este să știi ce există pe sistem, de ce există și dacă acea prezență este justificată.
Primul pas este inventarierea. Pe Linux, una dintre cele mai simple metode este comanda find. Pentru fișierele SUID poți folosi:
find / -xdev -type f -perm -4000
Pentru SGID:
find / -xdev -type f -perm -2000
Opțiunea -xdev ajută atunci când vrei să rămâi pe sistemul de fișiere curent și să nu scanezi tot ce este montat separat. Dacă vrei și mai mult context, poți afișa și proprietarul, grupul și permisiunile:
find / -xdev -type f -perm -4000 -printf ‘%m %u %g %pn’
find / -xdev -type f -perm -2000 -printf ‘%m %u %g %pn’
Aceste rezultate nu trebuie interpretate în grabă. Verificarea reală începe după listare. În primul rând, uită-te la cale: un fișier din /usr/bin sau /usr/sbin instalat de distribuție poate fi legitim, în timp ce unul apărut în /tmp, /home sau într-un director obscur merită analizat imediat. În al doilea rând, verifică proprietarul și pachetul din care provine. Pe distribuțiile bazate pe Debian poți folosi dpkg -S /cale/către/fișier, iar pe RHEL, Rocky, AlmaLinux sau Fedora, rpm -qf /cale/către/fișier. Dacă fișierul nu aparține niciunui pachet cunoscut, acesta este un semnal de alarmă clar.
Mai departe, compară rezultatele cu un baseline intern. Un audit util nu înseamnă doar să vezi ce există azi, ci să știi ce s-a schimbat față de luna trecută. Dacă apare un binar nou cu SUID sau SGID după instalarea unei aplicații, a unei unelte administrative sau a unui script intern, întreabă-te dacă schimbarea a fost documentată și aprobată. În mediile de business, tocmai lipsa acestui control transformă o configurație tehnică banală într-un risc operațional.
De ce trebuie verificate periodic? Pentru că aceste fișiere au privilegiu ridicat prin design. Dacă programul are un bug de securitate, dacă a fost înlocuit abuziv sau dacă permisiunile au fost setate greșit, impactul poate fi mai mare decât la un fișier obișnuit. Nu înseamnă că orice SUID duce automat la compromitere, dar înseamnă că merită tratat ca punct sensibil. Documentația Linux despre permisiuni speciale subliniază clar că un program SUID rulează cu identitatea proprietarului, iar asta schimbă complet modelul de risc.
Ce merită verificat concret? Proprietarul fișierului, grupul, locația, data modificării, proveniența dintr-un pachet legitim și necesitatea de business. Dacă un utilitar nu mai este folosit, eliminarea pachetului este de regulă mai sigură decât păstrarea lui „pentru orice eventualitate”. Dacă aplicația este necesară, actualizările de securitate trebuie urmărite cu atenție, iar integritatea fișierelor ar trebui verificată prin mecanismele distribuției sau prin soluții de monitorizare.
Merită și o precizare practică: nu face schimbări în orb doar pentru că ai găsit multe rezultate. Eliminarea bitului SUID sau SGID de pe un fișier legitim poate strica funcții importante ale sistemului ori ale aplicațiilor. Mai sigur este să confirmi rolul fișierului, să verifici documentația distribuției și să testezi într-un mediu controlat înainte de orice modificare.
Pentru administratori, o rutină sănătoasă este simplă: listezi periodic fișierele SUID și SGID, compari cu o referință anterioară, investighezi orice diferență și documentezi excepțiile. Nu este un control spectaculos, dar este unul dintre acele obiceiuri care reduc riscul fără să complice inutil administrarea. În Linux, multe incidente nu pornesc de la ceva exotic, ci de la lucruri mici care au rămas neverificate prea mult timp.
