chroot epäonnistuu OpenVPN:ssä: AppArmor-sääntö vai käyttöoikeus?

Taustapalvelu kirjaa chroot-virheen ja profiili näyttää jo väljältä, joten houkutteleva korjaus on polkusäännön laajentaminen ja uudelleenkäynnistys. Se ei yleensä muuta mitään, koska chrootia säätelee käyttöoikeus, jota profiili ei koskaan pystynyt luovuttamaan. Sen päättäminen, mihin kerrokseen puuttua, vaatii kolme halpaa tarkistusta: mitä prosessi saa pitää hallussaan, mitä käytäntö sallii ja mitä käynnistäjä poisti ennen kuin kumpikaan niistä ehti merkitä.

Kaksi erillistä porttia, ja vain yksi kuuluu AppArmorille

chroot tarvitsee CAP_SYS_CHROOT-kyvyn käyttäjänimiavaruudessa, jossa prosessi toimii. Se on tavanomainen Linux-käyttöoikeus, jonka ydin tarkistaa ennen kuin kutsu tekee mitään poluille. Erikseen pakottava AppArmor-profiili voi evätä kyvyn, vaikka prosessilla olisi se, koska pakollista käytäntöä tarkastellaan tunnusten lisäksi eikä niiden sijaan. Ero on käytännössä merkittävä: kaksi kerrosta asuvat eri tiedostoissa, ja yleensä eri ihmiset ylläpitävät niitä.

Molemmat portit epäonnistuvat samalla errnolla. Kumpikin tuottaa EPERM-virheen, ja kumpikin näkyy yleisenä käyttöoikeusvalituksena taustapalvelun lokissa, minkä vuoksi profiilin sisällön arvaileminen tuhlaa niin paljon aikaa. Polkusääntö, jota olit juuri lisäämässä, säätelee tiedostopääsyä sen jälkeen, kun chroot onnistuu; sillä ei ole mitään tekemistä sen kanssa, onko toiminto ylipäänsä sallittu.

Kolmas portti on molempien yläpuolella. Jos palvelunhallinta tai kääre käynnisti prosessin ilman kykyä sen rajoitusjoukossa, mikään AppArmor-muutos ei voi palauttaa sitä, ja kykyjen lisääminen profiiliin vain dokumentoi aikomuksen, jota ydin ei kunnioita.

Lue käyttöoikeustila ennen käytännön muokkaamista

Aloita käynnissä olevasta prosessista, älä kokoonpanosta, jonka uskot olevan voimassa. Tilatiedosto paljastaa viisi kyvymaskia ja no-new-privileges-lipun, ja ne vastaavat eri kysymyksiin:

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

CapEff on kutsun kannalta ratkaiseva joukko: kyky, joka on CapBnd:ssä mutta puuttuu CapEff:stä, on katon sallima eikä ole tällä hetkellä hallussa. CapAmb on merkityksellinen, kun binaari ei ole etuoikeutettu tavanomaisessa setuid-mielessä, koska ympäristökyvyt ovat tapa, jolla palvelu säilyttää käyttöoikeuden execin yli ilman tiedostokykyjä. CapInh sisältää bittejä, jotka voivat periytyä execin yli, mutta vain kun suoritettavan tiedoston periytyvä joukko sallii sen, joten siellä oleva bitti ei yksinään myönnä mitään.

Varmista sitten, mikä profiili on todella liitetty. Prosessi voi olla rajoitettu profiilinimellä, jota et odottanut, varsinkin kun jakelu toimittaa oman yksikkötiedostonsa ja profiilinsa yhdessä, ja /proc/PID/attr/current ratkaisee asian yhdellä rivillä. Muokatun tiedostosi vertaaminen ytimen raportoimaan profiiliin on ero syyn korjaamisen ja tiedoston muokkaamisen välillä, jota kukaan ei lataa.

Lisää kyky sääntö vain, kun auditointijälki sanoo niin

Ytimen ja auditoinnin tietueet nimeävät kieltäytyneen kerroksen. Etsi kieltäytyminen, jossa on toiminto capable ja nimi sys_chroot sekä profiili, joka sen tuotti. Jos tietue on olemassa, prosessilla oli kyky jo hallussaan ja AppArmor kielsi sen, ja kohdennettu muutos on kyky sääntö todellisen profiilin sisällä:

capability sys_chroot,

Pidä se fragmenttina profiilissa, joka on aidosti liitetty, ja tarkista avainsana apparmor.d-profiiliviitteestä sen sijaan, että kopioisit säännön asiattomasta oppaasta. Jaetun includen sisään pudottaminen myöntää sen jokaiselle rajoitetulle ohjelmalle, joka lukee tiedoston, ja profiilin vaihtaminen complain-tilaan piilottaa seuraavan kieltäytymisen sen sijaan, että ratkaisisi tämän. Profiilisääntö poistaa käytäntökieltäytymisen; se ei luo käyttöoikeutta, joten prosessi, jolla ei koskaan ollut CAP_SYS_CHROOT-kykyä tehokkaassa joukossaan, epäonnistuu silti säännön kanssa.

Jos auditointitietue ei näytä lainkaan AppArmor-kieltäytymistä, lopeta profiilin muokkaaminen. Kyse on tunnusten ongelmasta, ja jäljellä oleva työ on yksikkötiedostossa tai vanhemmassa prosessissa, ei käytäntökielessä.

Palvelunhallinta pitää oman kattonsa

systemd asettaa jokaiselle palvelulle kykyjen rajoitusjoukon, ja oletuksena se joukko on kapea. Kaikki siellä suljettu pois on prosessille käyttämätöntä riippumatta siitä, mitä profiili sanoo, minkä vuoksi kovennetut yksiköt voivat epäonnistua toiminnossa, joka toimi, kun taustapalvelu käynnistettiin käsin. Asiaankuuluvat direktiivit on helppo lukea yksiköstä ja helppo jättää huomaamatta, kun sovellus raportoi virheen. Jakelupaketin toimittamat drop-init ovat tavallinen lähde katolle, jota kukaan ei muista määrittäneensä.

Katon nostaminen ja kyvyn myöntäminen ovat kaksi muutosta, eivät yksi. Rajoitusjoukon merkintä sanoo, että prosessi saa pitää kyvyn; se ei lisää sitä tehokkaaseen joukkoon, ja NoNewPrivs voi estää myöhemmän korotuksen onnistumisen, vaikka kaikki muu olisi kohdallaan. Lisää vain se, mitä toiminto tarvitsee, pidä muu kovennus ennallaan äläkä anna periksi kiusaukselle myöntää kaikki kyvyt yhden kutsun läpäisemiseksi.

Järjestyksellä on merkitystä tässäkin. Muuta ensin yksikön kattoa, varmista että CapEff sisältää nyt bitin, ja vasta sitten päätä, kieltääkö AppArmor edelleen. Molempien muutosten tekeminen kerralla jättää sinut taas arvailemaan, jos virhe jatkuu.

Kun kieltäytyminen on poistunut, tarkista vankila itse

Onnistunut chroot siirtää juuren, joten jokainen polku, jota taustapalvelu sen jälkeen koskee, ratkaistaan uudessa puussa. Puuttuva kokoonpano, puuttuva laitesolmu tai kopioimatta jäänyt varmenteen hakemisto näkyvät nyt tiedostovirheenä, ja se virhe on asettelun ongelma eikä kyvyn ongelma. Lue seuraava tapahtuma sen sijaan, että lisäät uuden laajan käyttöoikeuden. Siirto muuttaa myös sitä, mitä suhteellinen polku tarkoittaa, minkä vuoksi kovennusoppaat vaativat absoluuttisia polkuja taustapalvelun kokoonpanossa.

On myös hyvä muistaa, mitä chroot ei tee. Se on polun raja, ei hiekkalaatikko: prosessi, joka säilyttää käyttöoikeuden, voi paeta siitä, minkä vuoksi kyky yleensä pudotetaan kutsun jälkeen ja minkä vuoksi eristäminen pitää jättää taustapalvelun ympärille. AppArmor-profiilin, kykyjen rajoitusjoukon ja tiedostojärjestelmän rajoitusten pitäminen yhdessä on harjoituksen tarkoitus, ei jäljelle jäävä jäänne, joka poistetaan, kun palvelu käynnistyy.

Päätössääntö on lyhyt. Jos auditointitietue nimeää AppArmorin, lisää yksi kyky sääntö liitettyyn profiiliin. Jos tehokas joukko on tyhjä, korjaa yksikön katto ja käyttöoikeuden pudotusjärjestys. Jos profiili ei ole se, jota muokkasit, lopeta muokkaaminen ja etsi oikea.