Root într-un terminal, respins sub SELinux: de ce eșuează hook-ul

Rulați scriptul up ca root, acesta se termină, iar același script eșuează când serviciul îl invocă. Nimic din permisiunile fișierului nu s-a schimbat, așa că următorul pas natural este să le relaxați din nou, ceea ce nu repară nimic. Pe un host SELinux factorul decisiv nu este adesea cine este procesul, ci în ce domeniu rulează, iar root într-un domeniu restricționat rămâne restricționat.

Aceeași comandă, două domenii de securitate diferite

Aplicarea tipurilor evaluează împreună domeniul sursă, eticheta țintă și operația cerută. Sesiunea dumneavoastră de terminal rulează într-un domeniu neconstrâns sau administrativ, iar daemonul rulează în domeniul atribuit unității sale. De aceea comenzile identice produc decizii diferite, iar diferența este intenționată, nu un defect al politicii.

De aceea compararea celor două rulări este utilă doar dacă le comparați contextele. Rulați aceeași comandă din shell și din hook, iar versiunea din shell demonstrează că binarul există și că argumentele sunt corecte; nu demonstrează nimic despre dacă serviciul are voie să îl execute. Rulați-o ambele moduri și comparați domeniile, nu doar codurile de ieșire. Această comparație este cea care transformă o plângere vagă despre permisiuni într-o întrebare precisă despre un domeniu și o etichetă.

Forma clasică a acestei defecțiuni este un ajutor care apelează un instrument extern. Hook-ul în sine poate fi permis, în timp ce instrumentul pe care îl invocă poartă o etichetă pe care domeniul serviciului nu o poate executa, sau scrie într-un director a cărui etichetă interzice asta.

Citiți înregistrarea AVC lângă eroarea hook-ului

O respingere AVC numește câmpurile care decid cazul: contextul sursă al procesului, contextul țintă al obiectului, clasa obiectului și permisiunea specifică ce a fost refuzată. Citiți toate patru înainte de a formula o teorie, deoarece o respingere la execuție și una la scriere au reparații complet diferite.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

Contextul sursă ar trebui să corespundă domeniului în care serviciul rulează efectiv, iar contextul țintă etichetei fișierului sau directorului atins de operație. Dacă vreunul nu se potrivește cu eroarea pe care o urmăriți, citiți alt eveniment.

Notați versiunea politicii și calea exactă a executabilului lângă înregistrare. Un nume de domeniu care apare în politica unei distribuții este o dovadă despre acea instalare, nu o garanție că altă compilare livrează aceleași reguli. Acest context este cel care permite altcuiva să reproducă concluzia dumneavoastră pe propriul host. Fără el, înregistrarea se citește ca o anecdotă, nu ca o dovadă.

Etichetă, configurație sau politică: trei reparații

Prima reparație este o etichetă care nu corespunde locației instalate a fișierului. Un script copiat la locul lui cu cp sau scris de un editor poate purta o etichetă implicită pe care domeniul serviciului nu o poate folosi, iar restaurarea contextului așteptat rezolvă asta fără să atingă politica.

A doua este configurația. Distribuția poate oferi o modalitate acceptată de a rula operația, un director documentat pentru ajutor sau un pachet de politică actualizat care o permite deja. Schimbarea aspectului dumneavoastră pe cel acceptat este mai ieftină decât scrierea politicii și supraviețuiește actualizărilor.

A treia este o regulă cu adevărat lipsă, și ar trebui să fie ultima soluție. Generați un candidat cu instrumentele de audit, citiți ce permite de fapt, restrângeți-l la operația și domeniul pe care le-ați observat, și rugați pe altcineva să îl revizuiască înainte de a se apropia de producție.

De ce un modul allow vechi nu este răspunsul

Rezultatele căutării pentru această defecțiune sunt pline de module gata făcute, adesea pentru un instrument pe care hook-ul nu îl mai apelează. Instalarea unuia acordă permisiuni care poate nu au nimic de-a face cu respingerea dumneavoastră, și lasă nepotrivirea reală pe loc adăugând o gaură permanentă.

Ascunde și următorul eșec. Un modul care permite o clasă largă de operații va face această eroare să dispară și va transforma următoarea în ceva mult mai greu de atribuit. Îndepărtarea modulului mai târziu este și ea o schimbare pe care nimeni nu vrea să o planifice, așa că scurtătura tinde să devină permanentă.

Comparația disciplinată este între respingerea pe care o puteți citi și schimbarea pe care o propuneți. Ghidul de depanare SELinux al Red Hat pune verificările de etichetare și configurare înaintea politicii generate exact din acest motiv. Dacă nu există o respingere corespunzătoare în înregistrare, SELinux probabil nu este problema dumneavoastră, și problemele de cale, sandbox sau permisiuni rămân deschise.