Root terminalis, SELinuxi all keelatud: miks hook ebaõnnestub

Käivitate up-skripti root-kasutajana, see lõpeb, ja sama skript ebaõnnestub, kui teenus selle kutsub. Failiõigustes pole midagi muutunud, seega loomulik järgmine samm on neid uuesti lõdvendada, mis ei paranda midagi. SELinuxi hostis ei ole määrav tegur sageli mitte see, kes protsess on, vaid see, millises domeenis see töötab, ja root piiratud domeenis on endiselt piiratud.

Sama käsk, kaks erinevat turvadomeeni

Tüübipõhine jõustamine hindab lähtedomeeni, sihtsilti ja taotletavat toimingut koos. Teie terminaliseanss töötab piiramatus või administratiivses domeenis ning deemon töötab domeenis, mis on määratud selle üksusele. Seega annavad identsed käsud erinevaid otsuseid ja erinevus on kavatsuslik, mitte poliitika viga.

Seepärast on kahe käivituse võrdlemine kasulik ainult siis, kui võrdlete nende kontekste. Käivitage sama käsk kestast ja hookist; kesta versioon tõestab, et binaarfail on olemas ja argumendid on õiged, kuid ei tõesta midagi selle kohta, kas teenusel on luba seda käivitada. Käivitage seda mõlemal viisil ja võrrelge domeene, mitte ainult väljumiskoode. Just see võrdlus muudab ebamäärase õiguste kaebuse konkreetseks küsimuseks ühe domeeni ja ühe sildi kohta.

Selle rikke klassikaline kuju on abiprogramm, mis kutsub välise tööriista. Hook ise võib olla lubatud, samas kui tööriist, mida see kutsub, kannab silti, mida teenusedomeen ei tohi käivitada, või kirjutab kataloogi, mille silt seda keelab.

Lugege AVC-kirjet hooki vea kõrval

AVC keeld nimetab väljad, mis otsustavad juhtumi: protsessi lähtekontekst, objekti sihtkontekst, objektiklass ja konkreetne keelatud õigus. Lugege kõiki nelja enne teooria moodustamist, sest täitmise keeld ja kirjutamise keeld nõuavad täiesti erinevaid parandusi.

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

Lähtekontekst peaks vastama domeenile, milles teenus tegelikult töötab, ja sihtkontekst selle faili või kataloogi sildile, mida toiming puudutas. Kui kumbki neist ei klapi veaga, mida jälitate, loete teist sündmust.

Märkige kirje kõrvale poliitika versioon ja täpne käivitatava faili tee. Domeeni nimi, mis esineb ühe distributsiooni poliitikas, on tõend selle paigalduse kohta, mitte garantii, et teine koostis tarnib samad reeglid. Just see kontekst võimaldab kellelgi teisel teie järeldust oma hostis korrata. Ilma selleta loetakse kirjet anekdoodina, mitte tõendina.

Silt, konfiguratsioon või poliitika: kolm parandust

Esimene parandus on silt, mis ei vasta faili paigaldatud asukohale. cp-ga kohale kopeeritud või redaktoriga kirjutatud skript võib kanda vaikimisi silti, mida teenusedomeen ei saa kasutada, ja oodatud konteksti taastamine parandab selle ilma poliitikat üldse puutumata.

Teine on konfiguratsioon. Distributsioon võib pakkuda toetatud viisi toimingu käivitamiseks, dokumenteeritud kataloogi abiprogrammi jaoks või uuendatud poliitikapaketti, mis seda juba lubab. Oma paigutuse muutmine toetatud variandiks on odavam kui poliitika kirjutamine ja peab uuendustele vastu.

Kolmas on tõeliselt puuduv reegel ja see peaks olema viimane abinõu. Looge kandidaat audititööriistadega, lugege, mida see tegelikult lubab, kitsendage see toimingule ja domeenile, mida jälgisite, ja laske kellelgi teisel see üle vaadata, enne kui see tootmisele läheneb.

Miks vana allow-moodul ei ole vastus

Selle rikke otsingutulemused on täis valmismooduleid, sageli tööriista jaoks, mida hook enam ei kutsu. Ühe paigaldamine annab õigused, millel ei pruugi teie keeluga mingit seost olla, ja jätab tegeliku mittevastavuse paigale, lisades samal ajal püsiva augu.

See varjab ka järgmise rikke. Moodul, mis lubab laia toimingute klassi, paneb selle vea kaduma ja muudab järgmise palju raskemini omistatavaks. Mooduli hilisem eemaldamine on samuti muudatus, mida keegi ei taha planeerida, seega kipub lühike tee püsivaks jääma.

Distsiplineeritud võrdlus on loetava keelu ja teie pakutava muudatuse vahel. Red Hati SELinuxi tõrkeotsingu juhend asetab sildistamise ja konfiguratsiooni kontrollid loodud poliitika ette just sel põhjusel. Kui kirjes pole vastavat keeldu, pole SELinux tõenäoliselt teie probleem, ja tee, sandboxi või õiguste küsimused on endiselt lahtised.