Root v terminalu, zavrnjen pod SELinuxom: zakaj hook ne uspe
Hook, ki ročno deluje brezhibno, je lahko v storitvi zavrnjen. Pred urejanjem primerjajte domeno procesa, oznako datoteke in zavrnjeno dovoljenje.
Skript up zaženete kot root, konča se, in ista skripta ne uspe, ko jo storitev pokliče. Pri dovoljenjih datoteke se ni nič spremenilo, zato je naslednji naravni korak, da jih znova omilite, kar ne popravi ničesar. Na gostitelju s SELinuxom odločilni dejavnik pogosto ni, kdo je proces, ampak v kateri domeni deluje, in root znotraj omejene domene ostane omejen.
Isti ukaz, dve različni varnostni domeni
Uveljavljanje tipov ocenjuje izvorno domeno, ciljno oznako in zahtevano operacijo skupaj. Vaša terminalska seja deluje v neomejeni ali administrativni domeni, demon pa deluje v domeni, ki je dodeljena njegovi enoti. Zato enaki ukazi dajejo različne odločitve, in razlika je namerna ter ni napaka v politiki.
Zato je primerjava obeh zagonov koristna le, če primerjate njuna konteksta. Zaženite isti ukaz iz lupine in iz hooka; različica iz lupine dokazuje, da binarna datoteka obstaja in da so argumenti pravilni, ne dokazuje pa ničesar o tem, ali sme storitev ukaz izvesti. Zaženite ga na oba načina in primerjajte domene, ne le izhodnih kod. Prav ta primerjava spremeni nejasno pritožbo glede dovoljenj v konkretno vprašanje o eni domeni in eni oznaki.
Klasična oblika te napake je pomočnik, ki kliče zunanje orodje. Sam hook je lahko dovoljen, medtem ko orodje, ki ga kliče, nosi oznako, ki je domenska storitev ne sme izvesti, ali piše v imenik, katerega oznaka to prepoveduje.
Preberite zapis AVC ob napaki hooka
Zavrnitev AVC navaja polja, ki odločijo primer: izvorni kontekst procesa, ciljni kontekst objekta, razred objekta in konkretno dovoljenje, ki je bilo zavrnjeno. Preberite vse štiri, preden oblikujete teorijo, ker imata zavrnitev izvajanja in zavrnitev pisanja povsem različna popravka.
ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn
Izvorni kontekst bi moral ustrezati domeni, v kateri storitev dejansko deluje, ciljni kontekst pa oznaki datoteke ali imenika, ki se ga je operacija dotaknila. Če se kateri od njiju ne ujema z napako, ki ji sledite, berete drug dogodek.
Ob zapisu si zabeležite različico politike in natančno pot do izvršljive datoteke. Ime domene, ki se pojavi v politiki ene distribucije, je dokaz o tej namestitvi, ne pa zagotovilo, da bo druga gradnja dobavila ista pravila. Prav ta kontekst nekomu drugemu omogoča, da ponovi vaš sklep na svojem gostitelju. Brez njega se zapis bere kot anekdota in ne kot dokaz.
Oznaka, konfiguracija ali politika: trije popravki
Prvi popravek je oznaka, ki se ne ujema z nameščeno lokacijo datoteke. Skripta, kopirana na svoje mesto s cp ali napisana z urejevalnikom, lahko nosi privzeto oznako, ki je domenska storitev ne more uporabiti, in obnovitev pričakovanega konteksta to odpravi, ne da bi se politike sploh dotaknili.
Drugi je konfiguracija. Distribucija lahko ponuja podprt način izvajanja operacije, dokumentiran imenik za pomočnika ali posodobljen paket politike, ki to že dovoljuje. Spreminjanje vaše postavitve v podprto je cenejše od pisanja politike in preživi posodobitve.
Tretji je resnično manjkajoče pravilo in bi moralo biti zadnja možnost. Ustvarite kandidata z revizijskimi orodji, preberite, kaj dejansko dovoljuje, zožite ga na operacijo in domeno, ki ste ju opazovali, in prosite nekoga drugega, da ga pregleda, preden se približa produkciji.
Zakaj star allow modul ni odgovor
Rezultati iskanja za to napako so polni pripravljenih modulov, pogosto za orodje, ki ga hook ne kliče več. Namestitev enega podeli dovoljenja, ki morda nimajo nobene zveze z vašo zavrnitvijo, in resnično neskladje pusti na mestu, medtem ko doda trajno luknjo.
Skrije tudi naslednjo napako. Modul, ki dovoljuje širok razred operacij, bo to napako odstranil in naslednjo spremenil v nekaj veliko težje pripisljivega. Odstranitev modula pozneje je tudi sprememba, ki je nihče noče načrtovati, zato bližnjica ponavadi postane trajna.
Disciplinirana primerjava je med zavrnitvijo, ki jo lahko preberete, in spremembo, ki jo predlagate. Priročnik Red Hat za odpravljanje težav s SELinuxom postavlja preverjanja oznak in konfiguracije pred ustvarjeno politiko prav zaradi tega razloga. Če v zapisu ni ustrezne zavrnitve, SELinux verjetno ni vaša težava, in vprašanja poti, sandboxa ali dovoljenj ostajajo odprta.