chroot nepavyksta OpenVPN: AppArmor taisyklė ar galimybė?

Demonas registruoja chroot nesėkmę, o profilis jau atrodo dosnus, todėl viliojantis sprendimas yra išplėsti maršruto taisyklę ir paleisti iš naujo. Paprastai tai nieko nekeičia, nes chroot valdo privilegija, kurios profilis niekada negalėjo perduoti. Norint nuspręsti, kurio sluoksnio liesti, reikia trijų pigių patikrų: ką procesui leidžiama laikyti, ką leidžia politika ir ką paleidėjas pašalino prieš abiem tampant svarbiems.

Du atskiri vartai, ir tik vieni priklauso AppArmor

chroot reikalauja CAP_SYS_CHROOT vartotojo vardų erdvėje, kurioje veikia procesas. Tai įprasta Linux privilegija, kurią branduolys patikrina prieš iškvietimui ką nors darant su maršrutais. Atskirai, vykdantis AppArmor profilis gali atmesti galimybę net tada, kai procesas ją turi, nes privalomoji politika tikrinama prie prisijungimo duomenų, o ne vietoj jų. Skirtumas praktiškai svarbus: du sluoksniai gyvena skirtinguose failuose ir paprastai juos prižiūri skirtingi žmonės.

Tie du vartai nepavyksta su tuo pačiu errno. Abu sukuria EPERM, ir abu pasirodo kaip bendras leidimų skundas demono žurnale, todėl spėliojimas apie profilio turinį švaisto tiek daug laiko. Maršruto taisyklė, kurią ketinote pridėti, kontroliuoja failų prieigą po to, kai chroot pavyksta; ji neturi nieko bendra su tuo, ar operacija apskritai leidžiama.

Treči vartai yra aukščiau abiejų. Jei paslaugų tvarkyklė ar apvalkalas paleido procesą be galimybės savo ribinėje aibėje, joks AppArmor pakeitimas negali jos grąžinti, o galimybių pridėjimas prie profilio tik dokumentuoja ketinimą, kurio branduolys negerbs.

Perskaitykite privilegijų būseną prieš redaguodami politiką

Pradėkite nuo veikiančio proceso, o ne nuo konfigūracijos, kurią laikote aktyvia. Būsenos failas atskleidžia penkias galimybių kaukes ir no-new-privileges požymį, ir jie atsako į skirtingus klausimus:

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

CapEff yra aibė, kuri svarbi iškvietimui: galimybė, esanti CapBnd, bet nesanti CapEff, yra leidžiama lubų ir šiuo metu nelaikoma. CapAmb svarbi, kai dvejetainis failas nėra privilegijuotas įprasta setuid prasme, nes aplinkos galimybės yra būdas, kuriuo paslauga išlaiko privilegiją per exec be failo galimybių. CapInh turi bitų, kurie gali būti paveldimi per exec, bet tik kai vykdomo failo paveldimoji aibė tai leidžia, todėl ten esantis bitas pats savaime nieko nesuteikia.

Tada patvirtinkite, koks profilis iš tikrųjų prijungtas. Procesas gali būti apribotas profilio vardu, kurio nesitikėjote, ypač kai distribucija siunčia savo unit failą ir profilį kartu, o /proc/PID/attr/current perskaitymas tai išsprendžia viena eilute. Savo redaguoto failo palyginimas su profiliu, kurį praneša branduolys, yra skirtumas tarp priežasties taisymo ir failo, kurio niekas nekrauna, redagavimo.

Pridėkite galimybės taisyklę tik tada, kai audito pėdsakas taip sako

Branduolio ir audito įrašai įvardija atmetusį sluoksnį. Ieškokite atmetimo, kuris turi operaciją capable ir vardą sys_chroot, kartu su jį sukūrusiu profiliu. Jei toks įrašas yra, procesas jau turėjo galimybę, o AppArmor ją atmetė, ir tikslingas pakeitimas yra galimybės taisyklė tikrame profilyje:

capability sys_chroot,

Laikykite ją fragmentu profilyje, kuris tikrai prijungtas, ir patikrinkite raktinį žodį pagal apparmor.d profilių nuorodą, o ne kopijuokite taisyklę iš nesusijusio vadovo. Įdėjus ją į bendrą include, ji suteikiama kiekvienai apribotai programai, kuri įtraukia tą failą, o profilio perkėlimas į complain režimą paslėps kitą atmetimą, o ne išspręs šį. Profilio taisyklė pašalina politikos atmetimą; ji negamina privilegijos, todėl procesas, kurio veiksmingoje aibėje niekada nebuvo CAP_SYS_CHROOT, vis tiek nepavyks net su taisykle.

Jei audito įrašas visai nerodo AppArmor atmetimo, nustokite redaguoti profilį. Jūs matote prisijungimo duomenų problemą, o likęs darbas yra unit faile arba tėviniame procese, ne politikos kalboje.

Paslaugų tvarkyklė laiko savo lubas

systemd kiekvienai paslaugai nustato galimybių ribinę aibę, ir pagal nutylėjimą ta aibė siaura. Viskas, kas ten išbraukta, procesui neprieinama, kad ir ką sakytų profilis, todėl sustiprinti unit gali nepavykti atlikti operacijos, kuri veikė, kai demonas buvo paleistas rankiniu būdu. Atitinkamas direktyvas lengva perskaityti unite ir lengva nepastebėti, kai programa praneša apie klaidą. Platinimo paketo siunčiami drop-in failai yra įprastas šaltinis lubų, kurių niekas neprisimena konfigūravęs.

Lubų pakėlimas ir galimybės suteikimas yra du pakeitimai, ne vienas. Ribinės aibės įrašas sako, kad procesas gali turėti galimybę; jis neprideda jos prie veiksmingos aibės, o NoNewPrivs gali sutrukdyti vėlesniam pakėlimui pavykti net tada, kai visa kita dera. Pridėkite tik tai, ko reikia operacijai, išlaikykite likusį sustiprinimą ir atsispirkite pagundai suteikti visas galimybes, kad vienas iškvietimas praeitų.

Tvarka čia taip pat svarbi. Pirmiausia pakeiskite unit lubas, patikrinkite, ar CapEff dabar turi bitą, ir tik tada spręskite, ar AppArmor vis dar atmeta. Abiejų pakeitimų darymas iš karto vėl palieka jus spėlioti, jei klaida išlieka.

Kai atmetimas išnyksta, patikrinkite pačią kalėjimą

Sėkmingas chroot perkelia šaknį, todėl kiekvienas maršrutas, kurį demonas vėliau paliečia, sprendžiamas naujame medyje. Trūkstama konfigūracija, nesančio įrenginio mazgas ar nenukopijuotas sertifikatų katalogas dabar pasirodys kaip failo klaida, ir ta klaida yra išdėstymo, o ne galimybės problema. Skaitykite kitą įvykį, o ne pridėkite dar vieną plačią atleidimą. Perkėlimas keičia ir santykinio maršruto prasmę, todėl sustiprinimo vadovai reikalauja absoliučių maršrutų demono konfigūracijoje.

Taip pat naudinga prisiminti, ko chroot nedaro. Tai maršruto riba, o ne smėlio dėžė: procesas, kuris išlaiko privilegiją, gali iš jos pabėgti, todėl galimybė paprastai numetama po iškvietimo ir todėl izoliavimas turi likti aplink demoną. AppArmor profilio, galimybių ribinės aibės ir failų sistemos apribojimų laikymas kartu yra šio pratimo tikslas, o ne likutis, kurį reikia pašalinti paslaugai paleidus.

Sprendimo taisyklė trumpa. Jei audito įrašas įvardija AppArmor, pridėkite vieną galimybės taisyklę prie prijungto profilio. Jei veiksminga aibė tuščia, sutvarkykite unit lubas ir privilegijos numetimo tvarką. Jei profilis ne tas, kurį redagavote, nustokite redaguoti ir raskite tikrąjį.