chroot misluk op OpenVPN: AppArmor-reël of vermoë?

Die daemon log 'n chroot-mislukking en die profiel lyk reeds ruim, so die verleidelike oplossing is om 'n padreel te verbreed en weer te begin. Dit verander gewoonlik niks, want chroot word deur 'n voorreg beheer wat die profiel nooit kon oordra nie. Om te besluit watter laag om aan te raak verg drie kontroles, en hulle is goedkoop: wat die proses mag hou, wat die beleid toelaat, en wat die lanseerder verwyder het voordat enige van daardie twee saak gemaak het.

Twee afsonderlike hekke, en net een behoort aan AppArmor

chroot benodig CAP_SYS_CHROOT in die gebruikersnaamruimte waarin die proses loop. Dit is gewone Linux-voorreg, deur die kern nagegaan voordat die oproep enigiets met paaie doen. Afsonderlik kan 'n afdwingende AppArmor-profiel die vermoë weier selfs wanneer die proses dit het, want verpligte beleid word by die geloofsbriewe bygevoeg eerder as in hulle plek. Die onderskeid maak in die praktyk saak: die twee lae woon in verskillende lêers en word gewoonlik deur verskillende mense onderhou.

Daardie twee hekke misluk met dieselfde errno. Albei lewer EPERM, en albei verskyn as 'n generiese toestemmingsklag in die daemon-log, wat is waarom raaiwerk oor profielinhoud soveel tyd mors. Die padreel wat jy op die punt was om by te voeg beheer lêertoegang nadat die chroot geslaag het; dit het geen invloed op of die bewerking hoegenaamd toegelaat word nie.

'n Derde hek sit stroomop van albei. As die diensbestuurder of 'n omhulsel die proses begin het sonder die vermoë in sy begrensingstel, kan geen AppArmor-verandering dit terugbring nie, en om vermoëns by die profiel te voeg dokumenteer bloot 'n bedoeling wat die kern nie sal eerbiedig nie.

Lees die voorregtoestand voordat jy beleid wysig

Begin by die lopende proses eerder as by die konfigurasie wat jy glo aktief is. Die statuslêer stel vyf vermoemaskers en die no-new-privileges-vlag bloot, en hulle beantwoord verskillende vrae:

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

CapEff is die stel wat vir die oproep saak maak: 'n vermoë wat in CapBnd teenwoordig is maar in CapEff afwesig is, word deur die plafon toegelaat en nie tans gehou nie. CapAmb maak saak wanneer die binêre lêer nie op die gewone setuid-manier bevoorreg is nie, want omringende vermoëns is hoe 'n diens 'n voorreg oor exec heen behou sonder lêervermoëns. CapInh hou bisse wat oor exec geërf kan word, maar net wanneer die uitgevoerde lêer se erfbare stel dit toelaat, dus 'n bis daar verleen niks op sy eie nie.

Bevestig dan watter profiel werklik aangeheg is. 'n Proses kan deur 'n profielnaam beperk word wat jy nie verwag het nie, veral wanneer 'n distribusie sy eie eenheidlêer en profiel saam versend, en die lees van /proc/PID/attr/current besleg dit in een reël. Om jou gewysigde lêer met die profiel wat die kern rapporteer te vergelyk is die verskil tussen die oorsaak regmaak en 'n lêer wysig wat niemand laai nie.

Voeg die vermoëreël net by wanneer die ouditspoor dit se

Kern- en ouditrekords noem die laag wat weier. Soek na 'n weiering wat die bewerking capable en die naam sys_chroot dra, saam met die profiel wat dit voortgebring het. As daardie rekord bestaan, het die proses die vermoë reeds gehad en AppArmor het dit geweier, en die gerigte verandering is 'n vermoëreël binne die werklike profiel:

capability sys_chroot,

Hou dit as 'n fragment in die profiel wat werklik aangeheg is, en kontroleer die sleutelwoord teen die apparmor.d-profielverwysing eerder as om 'n reël uit 'n onverwante handleiding te kopieer. Om dit in 'n gedeelde insluiting te plaas verleen dit aan elke beperkte program wat daardie lêer intrek, en om profiele na kla-modus te skakel verberg die volgende weiering in plaas daarvan om hierdie een op te los. Die profielreel verwyder 'n beleidweiering; dit skep nie voorreg nie, dus 'n proses wat nooit CAP_SYS_CHROOT in sy effektiewe stel gehad het nie sal steeds misluk met die reël in plek.

As die ouditrekord glad geen AppArmor-weiering toon nie, stop om die profiel te wysig. Jy kyk na 'n geloofsbrieweprobleem, en die oorblywende werk is in die eenheidlêer of die ouerproses, nie in die beleidstaal nie.

Die diensbestuurder hou sy eie plafon

systemd stel 'n vermoë-begrensingstel vir elke diens, en by verstek is daardie stel smal. Enigiets wat daar uitgesluit is, is vir die proses onbeskikbaar maak nie saak wat die profiel sê nie, wat is waarom geharde eenhede 'n bewerking kan laat misluk wat gewerk het toe die daemon met die hand begin is. Die betrokke richtlyne is maklik om in die eenheid te lees en maklik om oor die hoof te sien wanneer die toepassing die fout rapporteer. Drop-ins wat deur 'n distribusiepakket versend word is die gewone bron van 'n plafon wat niemand onthou om te konfigureer nie.

Om die plafon te verhoog en die vermoë toe te ken is twee veranderinge, nie een nie. 'n Inskrywing in die begrensingstel se die proses mag die vermoë hou; dit voeg dit nie by die effektiewe stel nie, en NoNewPrivs kan verhoed dat 'n latere verhoging slaag selfs wanneer alles anders in lyn is. Voeg net by wat die bewerking nodig het, hou die res van die verharding ongeskonde, en weerstaan die kortpad om elke vermoë toe te ken om een oproep te laat slaag.

Orde maak hier ook saak. Verander eers die eenheidplafon, verifieer dat CapEff nou die bis bevat, en besluit eers dan of AppArmor steeds weier. Om albei veranderinge gelyktydig te maak laat jou weer raai as die fout voortduur.

Nadat die weiering opgeklaar is, kontroleer die tronk self

'n Suksesvolle chroot skuif die wortel, dus elke pad wat die daemon daarna aanraak word binne die nuwe boom opgelos. Ontbrekende konfigurasie, 'n afwesige toestelknop of 'n sertifikaatgids wat nie ingekopieer is nie sal nou as 'n lêerfout verskyn, en daardie fout is 'n uitlegprobleem eerder as 'n vermoeprobleem. Lees die volgende gebeurtenis in plaas daarvan om nog 'n breë toestemming by te voeg. Die skuif verander ook wat 'n relatiewe pad beteken, wat is waarom verhardingsgidse daarop aandring dat die daemon-konfigurasie absolute paaie gebruik.

Dit help ook om te onthou wat chroot nie doen nie. Dit is 'n padgrens, nie 'n sandput nie: 'n proses wat die voorreg behou kan daaruit ontsnap, wat is waarom die vermoë gewoonlik na die oproep laat val word en waarom beperking rondom die daemon in plek moet bly. Om die AppArmor-profiel, die vermoë-begrensingstel en die leerstelselbeperkings saam te behou is die punt van die oefening, nie 'n oorskiet om te verwyder sodra die diens begin nie.

Die besluitreël is kort. As die ouditrekord AppArmor noem, voeg een vermoëreël by die aangehegte profiel. As die effektiewe stel leeg is, maak die eenheidplafon en die voorreglaat-val-orde reg. As die profiel nie die een is wat jy gewysig het nie, stop met wysig en vind die regte een.