chroot mislukkast på OpenVPN: AppArmor-regel eller kapabilitet?

Tenesta loggar ein chroot-feil og profilen ser alt romsleg ut, så den freistande løysinga er å utvide ein stiregel og starte på nytt. Det endrar vanlegvis ingenting, fordi chroot blir styrt av ein rettighet profilen aldri kunne overlevere. Å avgjere kva lag du skal ta i, krev tre billege kontrollar: kva prosessen får lov til å halde, kva policyen tillèt, og kva oppstartaren fjerna før nokon av dei to talde.

To separate portar, og berre éin høyrer til AppArmor

chroot treng CAP_SYS_CHROOT i brukarnamnerommet prosessen køyrer i. Det er ein vanleg Linux-rettighet, kontrollert av kjernen før kallet gjer noko med stiar. Separat kan ein handhevande AppArmor-profil nekte kapabiliteten sjølv når prosessen har han, fordi obligatorisk policy blir rådført i tillegg til legitimasjonen og ikkje i staden for han. Skilnaden tel i praksis: dei to laga bur i ulike filer og blir vanlegvis halde ved like av ulike folk.

Dei to portane feilar med same errno. Begge gir EPERM, og begge framstår som ei generell løyveklage i tenesteloggen, og difor kastar gjetting på profilinnhald bort så mykje tid. Stiregelen du var i ferd med å leggje til, styrer filtilgang etter at chroot lukkast; han har ingenting å gjere med om operasjonen i det heile er tillaten.

Ein tredje port ligg oppstraums for begge. Viss tenestebehandlaren eller ei innpakking starta prosessen utan kapabiliteten i det avgrensande settet sitt, kan inga AppArmor-endring setje han tilbake, og å leggje kapabilitetar til profilen dokumenterer berre ei intensjon kjernen ikkje vil respektere.

Les rettighetstilstanden før du redigerer policyen

Start frå den køyrande prosessen og ikkje frå konfigurasjonen du trur er aktiv. Statusfila viser fem kapabilitetsmasker og no-new-privileges-flaggja, og dei svarar på ulike spørsmål:

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

CapEff er settet som tel for kallet: ein kapabilitet som finst i CapBnd men manglar i CapEff, er tillaten av taket og blir ikkje halden no. CapAmb tel når binærfila ikkje er privilegert i vanleg setuid-forstand, fordi omgivnadskapabilitetar er måten ei teneste held på ein rettighet gjennom exec utan filkapabilitetar. CapInh held bitar som kan arvast gjennom exec, men berre når det arvbære settet til fila som blir køyrd tillèt det, så ein bit der gir ingenting åleine.

Stadfest deretter kva profil som faktisk er fest. Ein prosess kan vere sperra inne av eit profilnamn du ikkje venta, særleg når ein distribusjon sender si eiga einingfil og profil saman, og å lese /proc/PID/attr/current avgjer det på éi linje. Å samanlikne fila du redigerte med profilen kjernen rapporterer, er skilnaden mellom å rette årsaka og å redigere ei fil ingen lastar.

Legg til kapabilitetsregelen berre når revisjonssporet seier det

Kjerne- og revisjonsoppføringane namngir laget som nekta. Leit etter ei nekting som ber operasjonen capable og namnet sys_chroot, saman med profilen som produserte henne. Viss den oppføringa finst, hadde prosessen alt kapabiliteten og AppArmor nekta, og den målretta endringa er ein kapabilitetsregel inne i den verkelege profilen:

capability sys_chroot,

Hald henne som eit fragment i profilen som faktisk er fest, og kontroller nøkkelordet mot referansen for apparmor.d-profilar i staden for å kopiere ein regel frå ein urelatert rettleiar. Å setje henne i ein delt include gir henne til kvart innesperra program som dreg inn fila, og å byte profilen til complain-modus gøymer neste nekting i staden for å løyse denne. Profilregelen fjernar ei policynekting; han lagar ikkje rettigheter, så ein prosess som aldri hadde CAP_SYS_CHROOT i det effektive settet sitt, vil framleis feile med regelen på plass.

Viss revisjonsoppføringa ikkje viser noka AppArmor-nekting i det heile, slutt å redigere profilen. Du ser på eit legitimasjonsproblem, og det attverande arbeidet er i einingfila eller foreldreprosessen, ikkje i policyspråket.

Tenestebehandlaren held sitt eige tak

systemd set eit avgrensande kapabilitetssett for kvar teneste, og som standard er det settet trongt. Alt som er utelukka der, er utilgjengeleg for prosessen uansett kva profilen seier, og difor kan herda einingar feile i ein operasjon som verka når tenesta vart starta for hand. Dei relevante direktiva er lette å lese i einingfila og lette å sjå bort frå når applikasjonen melder feilen. Drop-in-filer frå distribusjonspakken er den vanlege kjelda til eit tak ingen hugsar å ha sett opp.

Å heve taket og å gi kapabiliteten er to endringar, ikkje éi. Ei oppføring i det avgrensande settet seier at prosessen kan halde kapabiliteten; ho legg han ikkje til det effektive settet, og NoNewPrivs kan hindre ei seinare heving frå å lukkast sjølv når alt anna stemmer. Legg berre til det operasjonen treng, hald resten av herdinga, og stå imot snarvegen med å gi alle kapabilitetar for at eitt kall skal gå gjennom.

Rekkjefølgja tel òg her. Endre taket i einingfila først, stadfest at CapEff no inneheld biten, og avgjer først då om AppArmor framleis nektar. Å gjere begge endringane samstundes lèt deg gjetta igjen viss feilen held fram.

Når nektinga er borte, kontroller fengselet sjølv

Ein vellukka chroot flyttar rota, så kvar sti tenesta rører etterpå, blir løyst inne i det nye treet. Manglande konfigurasjon, ein fråverande einingnode eller ein sertifikatkatalog som ikkje vart kopiert, vil no visast som ein filfeil, og den feilen er eit layoutproblem og ikkje eit kapabilitetsproblem. Les neste hending i staden for å leggje til nok ei brei løyve. Flyttinga endrar òg kva ein relativ sti tyder, og difor insisterer herdeveiledningar på absolutte stiar i tenestekonfigurasjonen.

Det hjelper òg å hugse kva chroot ikkje gjer. Det er ei stigrense, ikkje ein sandkasse: ein prosess som held på rettigheten, kan rømme, og difor blir kapabiliteten vanlegvis sleppt etter kallet, og difor skal innesperringa bli verande rundt tenesta. Å halde AppArmor-profilen, det avgrensande kapabilitetssettet og filsystemavgrensningane saman er poenget med øvinga, ikkje ein rest som blir fjerna når tenesta startar.

Avgjerdsregelen er kort. Viss revisjonsoppføringa namngir AppArmor, legg til éin kapabilitetsregel i den feste profilen. Viss det effektive settet er tomt, rett taket i einingfila og rekkjefølgja for å sleppe rettigheten. Viss profilen ikkje er den du redigerte, slutt å redigere og finn den verkelege.