chroot fejler på OpenVPN: AppArmor-regel eller capability?

Dæmonen logger en chroot-fejl, og profilen ser allerede rundhåndet ud, så den fristende løsning er at udvide en stiregel og genstarte. Det ændrer normalt ingenting, fordi chroot er bevogtet af et privilegium, som profilen aldrig kunne overdrage. At afgøre, hvilket lag der skal røres, kræver tre kontroller, og de er billige: hvad processen må holde, hvad politikken tillader, og hvad starteren fjernede, før nogen af de to ting havde betydning.

To adskilte porte, og kun den ene tilhører AppArmor

chroot kræver CAP_SYS_CHROOT i det brugernavnerum, processen kører i. Det er et almindeligt Linux-privilegium, og kernen kontrollerer det, før kaldet gør noget som helst med stier. Separat kan en håndhævende AppArmor-profil afvise evnen, selv når processen har den, fordi obligatorisk politik rådspørges oveni legitimationsoplysningerne og ikke i stedet for dem. Forskellen betyder noget i praksis: de to lag bor i forskellige filer og vedligeholdes normalt af forskellige mennesker.

De to porte fejler med den samme errno. Begge giver EPERM, og begge viser sig som en generisk tilladelsesklage i dæmonloggen, og derfor spilder gætteri på profilens indhold så meget tid. Den stiregel, du var ved at tilføje, styrer filadgang, efter chroot er lykkedes; den har ingen indflydelse på, om handlingen overhovedet er tilladt.

En tredje port ligger oven over begge. Hvis servicemanageren eller en wrapper startede processen uden evnen i sit grænsesæt, kan ingen AppArmor-ændring sætte den tilbage, og at føje evner til profilen dokumenterer blot en hensigt, som kernen ikke vil respektere.

Læs privilegiestatus, før du redigerer politik

Begynd ved den kørende proces i stedet for ved den konfiguration, du tror er aktiv. Statusfilen viser fem evnemasker og no-new-privileges-flaget, og de svarer på forskellige spørgsmål:

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

CapEff er det sæt, der betyder noget for kaldet: en evne, der findes i CapBnd men mangler i CapEff, er tilladt af loftet og holdes ikke i øjeblikket. CapAmb betyder noget, når binæren ikke er privilegeret i sædvanlig setuid-forstand, fordi ambiente evner er måden, en tjeneste beholder et privilegium gennem exec uden filevner. CapInh holder bits, der kan nedarves gennem exec, men kun når den kørte fils nedarvningssæt tillader det, så et bit der giver intet i sig selv.

Bekræft derefter, hvilken profil der faktisk er tilknyttet. En proces kan være begrænset af et profilnavn, du ikke forventede, især når en distribution leverer sin unit-fil og profil sammen, og læsning af /proc/PID/attr/current afgør det på én linje. At sammenligne din redigerede fil med den profil, kernen rapporterer, er forskellen mellem at rette årsagen og at redigere en fil, ingen indlæser.

Tilføj kun evnereglen, når revisionssporet siger det

Kerne- og revisionsposter navngiver det lag, der afviser. Se efter en afvisning, der bærer operationen capable og navnet sys_chroot, sammen med den profil, der frembragte den. Findes den post, havde processen allerede evnen, og AppArmor afviste den, og den målrettede ændring er en evneregel inde i den rigtige profil:

capability sys_chroot,

Behold den som et fragment i den profil, der reelt er tilknyttet, og kontrollér nøgleordet mod referencen for apparmor.d-profiler i stedet for at kopiere en regel fra en uvedkommende vejledning. Lægger du den i et delt include, giver du den til ethvert begrænset program, der trækker den fil ind, og at skifte profiler til complain-tilstand skjuler den næste afvisning i stedet for at løse denne. Profilreglen fjerner en politikafvisning; den skaber ikke privilegium, så en proces, der aldrig havde CAP_SYS_CHROOT i sit effektive sæt, vil stadig fejle med reglen på plads.

Hvis revisionsposten slet ikke viser nogen AppArmor-afvisning, så stop med at redigere profilen. Du ser på et legitimationsproblem, og det resterende arbejde er i unit-filen eller i forældreprocessen, ikke i politiksproget.

Servicemanageren har sit eget loft

systemd sætter et evnegrænsesæt for hver tjeneste, og som standard er det sæt snævert. Alt, der udelukkes der, er utilgængeligt for processen, uanset hvad profilen siger, og derfor kan hærdede units fejle på en handling, der virkede, da dæmonen blev startet i hånden. De relevante direktiver er nemme at læse i unit-filen og nemme at overse, når applikationen rapporterer fejlen. Drop-ins, som en distributionspakke leverer, er den sædvanlige kilde til et loft, som ingen husker at have konfigureret.

At hæve loftet og give evnen er to ændringer, ikke én. En post i grænsesættet siger, at processen må holde evnen; den føjer den ikke til det effektive sæt, og NoNewPrivs kan forhindre en senere forhøjelse i at lykkes, selv når alt andet passer. Tilføj kun det, handlingen har brug for, hold resten af hærdningen intakt, og modstå genvejen at give alle evner for at få ét kald igennem.

Rækkefølgen betyder også noget her. Ændr først unit'ens loft, verificér at CapEff nu indeholder bittet, og afgør først derefter, om AppArmor stadig afviser. Laver du begge ændringer på én gang, gætter du igen, hvis fejlen fortsætter.

Når afvisningen er væk, så kontrollér fængslet selv

Et vellykket chroot flytter roden, så enhver sti, dæmonen derefter rører, opløses inde i det nye træ. Manglende konfiguration, en fraværende enhedsknude eller en certifikatmappe, der ikke blev kopieret, vil nu vise sig som en filfejl, og den fejl er et layoutproblem, ikke et evneproblem. Læs den næste hændelse i stedet for at tilføje endnu en bred tilladelse. Flytningen ændrer også, hvad en relativ sti betyder, og derfor insisterer hærdningsvejledninger på absolutte stier i dæmonkonfigurationen.

Det hjælper også at huske, hvad chroot ikke gør. Det er en stigrænse, ikke en sandkasse: en proces, der beholder privilegiet, kan undslippe den, og derfor droppes evnen normalt efter kaldet, og derfor bør indeslutningen blive omkring dæmonen. At beholde AppArmor-profilen, evnegrænsesættet og filsystembegrænsningerne sammen er pointen med øvelsen, ikke en rest, der skal fjernes, så snart tjenesten starter.

Beslutningsreglen er kort. Hvis revisionsposten nævner AppArmor, tilføj én evneregel til den tilknyttede profil. Hvis det effektive sæt er tomt, ret unit'ens loft og rækkefølgen for at droppe privilegier. Hvis profilen ikke er den, du redigerede, så stop med at redigere og find den rigtige.