chroot ne uspijeva na OpenVPN-u: AppArmor pravilo ili sposobnost?

Demon u dnevnik upisuje neuspjeh chroot-a, a profil već izgleda darežljivo, pa je primamljiv popravak proširiti pravilo putanje i ponovo pokrenuti. To obično ne mijenja ništa, jer chroot čuva privilegija koju profil nikada nije mogao prenijeti. Odluka koji sloj dodirnuti traži tri provjere, i one su jeftine: šta procesu smije ostati, šta politika dopušta i šta je pokretač uklonio prije nego što je ijedno od toga postalo važno.

Dva odvojena vrata, a samo jedna pripadaju AppArmoru

chroot zahtijeva CAP_SYS_CHROOT u imenskom prostoru korisnika u kojem proces radi. To je uobičajena Linux privilegija i kernel je provjerava prije nego što poziv uopće dotakne putanje. Odvojeno, AppArmor profil u načinu provođenja može odbiti sposobnost i kad je proces ima, jer se obavezujuća politika konsultuje uz akreditive, a ne umjesto njih. Razlika je praktično važna: dva sloja žive u različitim datotekama i obično ih održavaju različiti ljudi.

Ta dva vrata padaju s istim errno. Oba daju EPERM i oba se u dnevniku demona pojavljuju kao općenita žalba na dozvole, zato nagađanje o sadržaju profila gubi toliko vremena. Pravilo putanje koje ste htjeli dodati kontroliše pristup datotekama nakon uspješnog chroot-a; ono nema nikakve veze s tim je li operacija uopće dopuštena.

Treća vrata stoje iznad oba. Ako je servisni menadžer ili neki omotač pokrenuo proces bez te sposobnosti u njegovom skupu granica, nikakva AppArmor promjena je ne može vratiti, a dodavanje sposobnosti u profil samo dokumentuje namjeru koju kernel neće poštovati.

Pročitajte stanje privilegija prije uređivanja politike

Pođite od procesa koji radi, a ne od konfiguracije za koju mislite da je aktivna. Datoteka stanja izlaže pet maski sposobnosti i zastavicu no-new-privileges, a one odgovaraju na različita pitanja:

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

CapEff je skup koji je važan za poziv: sposobnost prisutna u CapBnd ali odsutna iz CapEff dopuštena je plafonom i trenutno se ne drži. CapAmb je važan kad binarni fajl nije privilegovan u uobičajenom setuid smislu, jer su ambient sposobnosti način da servis zadrži privilegiju kroz exec bez datotečnih sposobnosti. CapInh drži bitove koji se mogu naslijediti kroz exec, ali samo kad to nasljedni skup izvršene datoteke dopušta, pa bit tamo sam po sebi ne daje ništa.

Zatim potvrdite koji je profil zaista priključen. Proces može biti ograničen imenom profila koje niste očekivali, posebno kad distribucija isporučuje svoju unit datoteku i profil zajedno, a čitanje /proc/PID/attr/current to rješava u jednom redu. Poređenje vaše izmijenjene datoteke s profilom koji kernel prijavljuje je razlika između popravljanja uzroka i uređivanja datoteke koju nitko ne učitava.

Dodajte pravilo sposobnosti samo kad revizijski trag to kaže

Zapisi kernela i revizije imenuju sloj koji odbija. Tražite odbijanje koje nosi operaciju capable i ime sys_chroot, zajedno s profilom koji ga je proizveo. Ako taj zapis postoji, proces je već držao sposobnost i AppArmor ju je odbio, a ciljana promjena je pravilo sposobnosti unutar pravog profila:

capability sys_chroot,

Držite ga kao fragment u profilu koji je stvarno priključen i provjerite ključnu riječ prema referenci za apparmor.d profile umjesto da kopirate pravilo iz nepovezanog tutorijala. Ako ga stavite u zajednički include, dajete ga svakom ograničenom programu koji povuče tu datoteku, a prebacivanje profila u način žalbe skriva sljedeće odbijanje umjesto da riješi ovo. Pravilo u profilu uklanja odbijanje politike; ono ne stvara privilegiju, pa će proces koji nikada nije imao CAP_SYS_CHROOT u efektivnom skupu i dalje pasti i s tim pravilom.

Ako revizijski zapis uopće ne pokazuje AppArmor odbijanje, prestanite uređivati profil. Pred vama je problem s akreditivima, a preostali posao je u unit datoteci ili roditeljskom procesu, ne u jeziku politike.

Servisni menadžer drži vlastiti plafon

systemd postavlja skup granica sposobnosti za svaku uslugu, a taj je skup po defaultu uzak. Sve što je tamo isključeno nedostupno je procesu bez obzira na to što profil kaže, zato ojačane unit datoteke mogu pasti na operaciji koja je radila kad je demon pokrenut ručno. Relevantne direktive lako se čitaju u unit datoteci i lako previđaju kad aplikacija prijavi kvar. Drop-in datoteke koje isporučuje paket distribucije uobičajen su izvor plafona koji se nitko ne sjeća da je konfigurisao.

Podizanje plafona i davanje sposobnosti dvije su promjene, ne jedna. Zapis u skupu granica kaže da proces smije držati sposobnost; on je ne dodaje u efektivni skup, a NoNewPrivs može spriječiti kasnije podizanje da uspije i kad se sve ostalo poklopi. Dodajte samo ono što operacija traži, sačuvajte ostatak ojačanja i oduprite se prečici da date sve sposobnosti kako bi jedan poziv prošao.

Redoslijed je i ovdje važan. Prvo promijenite plafon u unit datoteci, provjerite da CapEff sada sadrži bit, pa tek onda odlučite odbija li AppArmor još. Ako obje promjene napravite odjednom, pri trajnom kvaru opet nagađate.

Kad odbijanje nestane, provjerite sam zatvor

Uspješan chroot premješta korijen, pa se svaka putanja koju demon nakon toga dotakne razrješava unutar novog stabla. Nedostajuća konfiguracija, odsutan čvor uređaja ili direktorij certifikata koji nije kopiran sada će se pojaviti kao greška datoteke, a ta greška je problem rasporeda, ne sposobnosti. Čitajte sljedeći događaj umjesto da dodajete još jednu široku dozvolu. Premještanje mijenja i šta znači relativna putanja, zato vodiči za ojačanje insistiraju na apsolutnim putanjama u konfiguraciji demona.

Korisno je zapamtiti i šta chroot ne radi. To je granica putanja, ne pješčanik: proces koji zadrži privilegiju može pobjeći iz nje, zato se sposobnost obično spušta nakon poziva i zato ograničenje treba ostati oko demona. Zadržati AppArmor profil, skup granica sposobnosti i datotečna ograničenja zajedno je poenta vježbe, a ne ostatak koji treba ukloniti kad usluga startuje.

Pravilo odluke je kratko. Ako revizijski zapis imenuje AppArmor, dodajte jedno pravilo sposobnosti priključenom profilu. Ako je efektivni skup prazan, popravite plafon u unit datoteci i redoslijed spuštanja privilegija. Ako profil nije onaj koji ste uređivali, prestanite uređivati i pronađite pravi.