chroot ei õnnestu OpenVPN-is: kas AppArmori reegel või võime?

Deemon logib chroot-i ebaõnnestumise ja profiil näib juba helde, seega ahvatlev parandus on laiendada raja reeglit ja taaskäivitada. Tavaliselt ei muuda see midagi, sest chroot-i valvab privileeg, mida profiil ei saanud kunagi üle anda. Otsustamaks, millist kihti puutuda, on vaja kolme kontrolli ja need on odavad: mida protsessil on lubatud hoida, mida poliitika lubab ja mida käivitaja eemaldas enne, kui kumbki neist kahest tähtsust omas.

Kaks eraldi väravat ja ainult üks kuulub AppArmorile

chroot vajab CAP_SYS_CHROOT-i kasutaja nimeruumis, milles protsess töötab. See on tavaline Linuxi privileeg ja kernel kontrollib seda enne, kui kutse radadega midagi teeb. Eraldi võib jõustav AppArmori profiil võime keelata ka siis, kui protsessil see on, sest kohustuslikku poliitikat konsulteeritakse lisaks volitustele, mitte nende asemel. Vahe on praktikas oluline: kaks kihti elavad eri failides ja neid hooldavad tavaliselt eri inimesed.

Mõlemad väravad ebaõnnestuvad sama errno-ga. Mõlemad annavad EPERM-i ja mõlemad ilmuvad deemonilogis üldise õigustekaelusena, mistõttu profiili sisu arvamine kaotab nii palju aega. Rajareegel, mida kavatsesite lisada, reguleerib failile ligipääsu pärast chroot-i õnnestumist; see ei mõjuta, kas toiming on üldse lubatud.

Kolmas värav seisab mõlemast kõrgemal. Kui teenusehaldur või mähis käivitas protsessi ilma selle võimeta selle piiris, ei saa ükski AppArmori muudatus seda tagasi ja võimete lisamine profiilile dokumenteerib vaid kavatsust, mida kernel ei austa.

Lugege privileegi olekut enne poliitika muutmist

Alustage töötavast protsessist, mitte konfiguratsioonist, mida peate aktiivseks. Olekufail näitab viit võimemaski ja no-new-privileges lippu ning need vastavad eri küsimustele:

grep -E '^(CapInh|CapPrm|CapEff|CapBnd|CapAmb|NoNewPrivs):' /proc/$(pidof openvpn)/status
sudo aa-status | grep -i openvpn

CapEff on hulk, mis kutse jaoks loeb: võime, mis on CapBnd-is olemas, kuid CapEff-is puudub, on ülempiiri poolt lubatud ja seda praegu ei hoita. CapAmb loeb siis, kui binaarfail ei ole privilegeeritud tavapärases setuid-mõttes, sest ümbritsevad võimed on viis, kuidas teenus hoiab privileegi üle exec ilma failivõimeteta. CapInh hoiab bitte, mida saaks üle exec pärida, kuid ainult siis, kui käivitatava faili päritav hulk seda lubab, seega üks bitt seal ei anna iseenesest midagi.

Seejärel kinnitage, milline profiil on tegelikult külge pandud. Protsessi võib piirata profiilinimi, mida te ei oodanud, eriti kui distributsioon tarnib oma unit-faili ja profiili koos, ja /proc/PID/attr/current lugemine lahendab selle ühe reaga. Oma muudetud faili võrdlemine profiiliga, millest kernel teatab, on vahe põhjuse parandamise ja faili muutmise vahel, mida keegi ei laadi.

Lisage võimereegel ainult siis, kui auditi jälg seda ütleb

Kerneli ja auditi kirjed nimetavad keelava kihi. Otsige keeldumist, mis kannab toimingut capable ja nime sys_chroot, koos profiiliga, mis selle tekitas. Kui selline kirje on olemas, hoidis protsess võimet juba ja AppArmor keeldus sellest, ning sihitud muudatus on võimereegel tõelise profiili sees:

capability sys_chroot,

Hoidke seda fragmentdina profiilis, mis on tegelikult külge pandud, ja kontrollige märksõna apparmor.d profiilide viite järgi, selle asemel et kopeerida reegel kõrvalisest õpetusest. Jagatud include-i panemine annab selle igale piiratud programmile, mis selle faili sisse tõmbab, ja profiilide viimine kaebuste režiimi peidab järgmise keeldumise, selle asemel et see lahendada. Profiilireegel eemaldab poliitikakeeldumise; see ei loo privileegi, seega protsess, kelle efektiivses hulgas ei olnud kunagi CAP_SYS_CHROOT-i, ebaõnnestub ikkagi ka reegli olemasolul.

Kui auditikirje ei näita üldse ühtki AppArmori keeldumist, lõpetage profiili muutmine. Teil on volituste probleem ja ülejäänud töö on unit-failis või vanemprotsessis, mitte poliitika keeles.

Teenusehalduril on oma ülempiir

systemd seab igale teenusele võimete piirihulga ja vaikimisi on see hulk kitsas. Kõik, mis seal välistatakse, ei ole protsessile kättesaadav ükskõik mida profiil ütleb, mistõttu karastatud unit-id võivad ebaõnnestuda toimingus, mis töötas siis, kui deemon käivitati käsitsi. Asjakohaseid direktiive on unit-failist lihtne lugeda ja lihtne tähelepanuta jätta, kui rakendus veast teatab. Distributsioonipaketi tarnitud drop-in-id on tavaline allikas ülempiirile, mille seadistamist keegi ei mäleta.

Ülempiiri tõstmine ja võime andmine on kaks muudatust, mitte üks. Piirihulga kirje ütleb, et protsess tohib võimet hoida; see ei lisa seda efektiivsesse hulka ja NoNewPrivs võib takistada hilisemat tõstmist õnnestumast ka siis, kui kõik muu klapib. Lisage ainult see, mida toiming vajab, hoidke ülejäänud karastus puutumatuna ja vastustage kiusatusele anda kõik võimed, et üks kutse läbi läheks.

Ka järjekord loeb siin. Muutke esmalt unit-i ülempiiri, kontrollige, et CapEff sisaldab nüüd bitti, ja alles siis otsustage, kas AppArmor keeldub endiselt. Mõlema muudatuse korraga tegemine jätab teid püsiva vea korral jälle arvama.

Kui keeldumine on kadunud, kontrollige puuri ennast

Õnnestunud chroot liigutab juure, seega iga rada, mida deemon pärast puudutab, lahendatakse uue puu sees. Puuduv konfiguratsioon, puuduv seadmesõlm või kopeerimata jäänud sertifikaadikataloog ilmub nüüd failiveana ja see viga on paigutuse, mitte võime probleem. Lugege järgmist sündmust, selle asemel et lisada veel üks lai luba. Liigutamine muudab ka seda, mida tähendab suhteline rada, mistõttu karastusjuhised nõuavad deemonikonfiguratsioonis absoluutseid radu.

Kasulik on meeles pidada ka seda, mida chroot ei tee. See on radade piir, mitte liivakast: protsess, kes hoiab privileegi, saab sealt põgeneda, mistõttu võime tavaliselt pärast kutset maha visatakse ja mistõttu piiramine peaks jääma deemonile ümber. AppArmori profiili, võimete piirihulga ja failisüsteemi piirangute koos hoidmine on harjutuse mõte, mitte jääk, mida kohe teenuse käivitumisel eemaldada.

Otsustusreegel on lühike. Kui auditikirje nimetab AppArmori, lisage külge pandud profiilile üks võimereegel. Kui efektiivne hulk on tühi, parandage unit-i ülempiir ja privileegi mahaviskamise järjekord. Kui profiil ei ole see, mida muutsite, lõpetage muutmine ja leidke õige.