chroot dështon në OpenVPN: rregull AppArmor apo aftësi?

Daemoni regjistron një dështim chroot dhe profili tashmë duket bujar, kështu që rregullimi joshës është të zgjerohet një rregull rruge dhe të rindizet. Zakonisht kjo nuk ndryshon asgjë, sepse chroot kapet nga një privilegj që profili nuk ka mundur kurrë ta japë. Të vendosësh cilën shtresë të prekësh kërkon tri kontrolle, dhe ato janë të lira: çfarë lejohet të mbajë procesi, çfarë lejon politika dhe çfarë hoqi nisësi para se ndonjëra prej të dyjave të kishte rëndësi.

Dy porta të ndara, dhe vetëm njëra i përket AppArmor

chroot kërkon CAP_SYS_CHROOT në hapësirën e emrave të përdoruesit në të cilën procesi po ekzekutohet. Ky është privilegji konvencional i Linux, i kontrolluar nga kerneli para se thirrja të bëjë çfarëdo me rrugët. Veç kësaj, një profil AppArmor në regjim enforcing mund ta refuzojë aftësinë edhe kur procesi e mban, sepse politika e detyrueshme konsultohet përveç kredencialeve, jo në vend të tyre. Dallimi ka rëndësi në praktikë: të dyja shtresat jetojnë në skedarë të ndryshëm dhe zakonisht mirëmbahen nga njerëz të ndryshëm.

Të dyja portat dështojnë me të njëjtin errno. Të dyja prodhojnë EPERM, dhe të dyja shfaqen si një ankesë e përgjithshme lejeje në regjistrin e daemonit, prandaj hamendësimi i përmbajtjes së profilit humb kaq shumë kohë. Rregulli i rrugës që po shtoje kontrollon aksesin në skedarë pasi chroot të ketë sukses; ai nuk ka lidhje me atë nëse operacioni lejohet fare.

Një portë e tretë qëndron në rrjedhën e sipërme të të dyjave. Nëse menaxheri i shërbimeve ose një mbështjellës e nisi procesin pa aftësinë në grupin e tij kufizues, asnjë ndryshim AppArmor nuk mund ta kthejë atë, dhe shtimi i aftësive në profil thjesht dokumenton një qëllim që kerneli nuk do ta përmbushë.

Lexoni gjendjen e privilegjeve para se të redaktoni politikën

Filloni nga procesi që punon, jo nga konfigurimi që mendoni se është aktiv. Skedari i gjendjes shfaq pesë maska aftësish dhe flamurin no-new-privileges, dhe ato u përgjigjen pyetjeve të ndryshme:

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

CapEff është grupi që ka rëndësi për thirrjen: një aftësi e pranishme në CapBnd por që mungon në CapEff lejohet nga tavani dhe nuk mbahet në atë moment. CapAmb ka rëndësi kur binari nuk është i privilegjuar në kuptimin e zakonshëm setuid, sepse aftësitë ambientale janë mënyra se si një shërbim e mban një privilegj përtej exec pa aftësi skedari. CapInh mban bit që mund të trashëgoheshin përtej exec, por vetëm kur grupi i trashëgueshëm i skedarit të ekzekutuar e lejon, kështu që një bit atje nuk jep asgjë vetë.

Më pas konfirmoni cili profil është vërtet i bashkangjitur. Një proces mund të jetë i kufizuar nga një emër profili që nuk e prisnit, sidomos kur një distribucion sjell vetë njësinë dhe profilin e vet bashkë, dhe leximi i /proc/PID/attr/current e zgjidh këtë në një rresht. Krahasimi i skedarit tuaj të redaktuar me profilin që raporton kerneli është dallimi midis rregullimit të shkakut dhe redaktimit të një skedari që askush nuk e ngarkon.

Shtojeni rregullin e aftësisë vetëm kur gjurma e auditimit e thotë

Regjistrat e kernelit dhe të auditimit emërtojnë shtresën që refuzoi. Kërkoni një refuzim që mban operacionin capable dhe emrin sys_chroot, së bashku me profilin që e prodhoi. Nëse ai regjistër ekziston, procesi e kishte tashmë aftësinë dhe AppArmor e refuzoi, dhe ndryshimi i synuar është një rregull aftësie brenda profilit të vërtetë:

capability sys_chroot,

Mbajeni si fragment në profilin që është vërtet i bashkangjitur, dhe kontrolloni fjalën kyçe te referenca e profileve apparmor.d në vend që të kopjoni një rregull nga një udhëzues i palidhur. Vendosja e tij në një include të përbashkët ua jep atë çdo programi të kufizuar që e ngarkon atë skedar, dhe kalimi i profilit në regjim complain e fsheh refuzimin tjetër në vend që ta zgjidhë këtë. Rregulli i profilit heq një refuzim politike; nuk prodhon privilegj, kështu që një proces që nuk e kishte kurrë CAP_SYS_CHROOT në grupin e tij efektiv do të dështojë edhe me rregullin në vend.

Nëse regjistri i auditimit nuk tregon fare refuzim AppArmor, ndaloni së redaktuarit e profilit. Po përballeni me një problem kredencialesh, dhe puna e mbetur është në njësi ose në procesin prind, jo në gjuhën e politikës.

Menaxheri i shërbimeve mban tavanin e vet

systemd vendos një grup kufizues aftësish për çdo shërbim, dhe si parazgjedhje ai grup është i ngushtë. Çdo gjë e përjashtuar atje është e padisponueshme për procesin, pavarësisht se çfarë thotë profili, prandaj njësitë e forcuara mund të dështojnë në një operacion që funksiononte kur daemoni nisej me dorë. Direktivat përkatëse lexohen lehtë në njësi dhe anashkalohen lehtë kur vetë aplikacioni raporton dështimin. Drop-in-et e dhëna nga një paketë e distribucionit janë burimi i zakonshëm i një tavani që askush nuk kujtohet ta ketë konfiguruar.

Ngritja e tavanit dhe dhënia e aftësisë janë dy ndryshime, jo një. Një zë në grupin kufizues thotë se procesi mund ta mbajë aftësinë; ai nuk e shton atë në grupin efektiv, dhe NoNewPrivs mund të pengojë suksesin e një ngritjeje të mëvonshme edhe kur çdo gjë tjetër përputhet. Shtoni vetëm atë që i duhet operacionit, mbani pjesën tjetër të forcimit të paprekur dhe kundërshtoni shkurtoresën e dhënies së të gjitha aftësive që të kalojë një thirrje e vetme.

Rendi ka rëndësi edhe këtu. Ndryshoni së pari tavanin e njësisë, verifikoni që CapEff tani e përmban bitin, dhe vetëm atëherë vendosni nëse AppArmor ende refuzon. Kryerja e të dyja ndryshimeve njëherësh ju lë përsëri duke hamendësuar nëse dështimi vazhdon.

Pasi refuzimi të zhduket, kontrolloni vetë burgun

Një chroot i suksesshëm e zhvendos rrënjën, kështu që çdo rrugë që daemoni prek më pas zgjidhet brenda pemës së re. Konfigurimi që mungon, një nyje pajisjeje e pazakonshme ose një drejtori certifikatash që nuk u kopjua tani do të shfaqen si gabim skedari, dhe ai gabim është problem rregullimi, jo aftësie. Lexoni ngjarjen tjetër në vend që të shtoni një leje tjetër të gjerë. Zhvendosja ndryshon edhe kuptimin e një rruge relative, prandaj udhëzuesit e forcimit këmbëngulin për rrugë absolute në konfigurimin e daemonit.

Ndihmon edhe të kujtojmë çfarë nuk bën chroot. Është një kufi rruge, jo një sandbox: një proces që e mban privilegjin mund të dalë prej tij, prandaj aftësia zakonisht hidhet pas thirrjes dhe prandaj kufizimi duhet të mbetet rreth daemonit. Mbajtja së bashku e profilit AppArmor, e grupit kufizues të aftësive dhe e kufizimeve të sistemit të skedarëve është qëllimi i ushtrimit, jo një mbetje për t'u hequr pasi shërbimi niset.

Rregulli i vendimit është i shkurtër. Nëse regjistri i auditimit emërton AppArmor, shtoni një rregull aftësie në profilin e bashkangjitur. Nëse grupi efektiv është bosh, rregulloni tavanin e njësisë dhe rendin e heqjes së privilegjeve. Nëse profili nuk është ai që redaktualli, ndaloni së redaktuarit dhe gjeni atë të vërtetin.