chroot mislearret op OpenVPN: AppArmor-regel of fermogen?

De daemon skriuwt in chroot-mislearring yn it loch en it profyl liket al rom, dat de ferliedlike oplossing is in paadregel te ferbreedzjen en wer te starten. Dat feroaret meastentiids neat, want chroot wurdt beweiligen troch in privileezje dat it profyl nea oerdrage koe. Om te besluten hokker laach jo oanreitsje moatte, binne trije kontrôles nedich, en se binne goedkeap: wat it proses hâlde mei, wat it belied tastiet en wat de starter fuorthelle eardat ien fan beide saak die.

Twa aparte poarten, en mar ien heart by AppArmor

chroot hat CAP_SYS_CHROOT nedich yn 'e brûkersnamromte dêr't it proses yn rint. Dat is in gewoan Linux-privileezje, en de kearn kontrolearret it eardat de oprop eat mei paden docht. Apart dêrfan kin in hanthavenjend AppArmor-profyl it fermogen wegerje sels as it proses it hat, want ferplicht belied wurdt rieplachte njonken de legitimearring, net yn har plak. It ferskil is yn 'e praktyk wichtich: de twa lagen wenje yn ferskillende bestannen en wurde meast troch ferskillende minsken ûnderholden.

Dy twa poarten mislearje mei deselde errno. Beide jouwe EPERM, en beide ferskine as in algemiene tastimming-beswier yn it daemonloch, dêrom kostet it rieden oer profylynhâld safolle tiid. De paadregel dy't jo tafoegje woene, regelet bestânstagonk neidat chroot slagge is; hy hat gjin ynfloed op oft de begearing oait tastien is.

In tredde poarte stiet boppe beide. As de tsjinstbehearder of in wraksel it proses starte hat sûnder it fermogen yn syn grinsset, kin gjin AppArmor-wiziging it weromsette, en it tafoegjen fan fermogens oan it profyl dokumintearret allinnich in bedoeling dy't de kearn net respektearret.

Lês de privileezjestatus foardat jo belied bewurkje

Begjin by it rinnende proses, net by de konfiguraasje dy't jo aktyf achtsje. It statusbestân lit fiif fermogensmasken en de no-new-privileges-flagge sjen, en se beantwurdzje ferskillende fragen:

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

CapEff is de set dy't foar de oprop fan belang is: in fermogen dat yn CapBnd sit mar yn CapEff mist, is troch it plafond tastien en wurdt op dit stuit net hâlden. CapAmb is fan belang as it binêre bestân net privilezjearre is yn 'e gewoane setuid-betsjutting, want omjouwingsfermogens binne de manier wêrop in tsjinst in privileezje oer exec hinne hâldt sûnder bestânsfermogens. CapInh hâldt bits dy't oer exec erfd wurde kinne, mar allinnich as de erflike set fan it útfierde bestân dat tastiet, dus in bit dêr jout op himsels neat.

Befêstigje dan hokker profyl echt oanheakke is. In proses kin beheind wurde troch in profylnamme dy't jo net ferwachten, benammen as in distribúsje syn eigen unit-bestân en profyl tegearre leveret, en it lêzen fan /proc/PID/attr/current beslist dat yn ien rigel. Jo bewurke bestân ferlykje mei it profyl dat de kearn rapportearret is it ferskil tusken de oarsaak reparearje en in bestân bewurkje dat nimmen laadt.

Foegje de fermogensregel allinnich ta as it audyspoar dat seit

Kearn- en auditrecords neame de laach dy't wegeret. Sykje in wegering dy't de begearing capable en de namme sys_chroot draacht, tegearre mei it profyl dat dy produsearre. Bestiet dat record, dan hie it proses it fermogen al en AppArmor wegere it, en de rjochte wiziging is in fermogensregel binnen it echte profyl:

capability sys_chroot,

Hâld it as fragmint yn it profyl dat echt oanheakke is, en kontrolearje it kaaiwurd tsjin de referinsje foar apparmor.d-profylen ynstee fan in regel út in net besibbe hânlieding te kopiearjen. Yn in dielde include jout it it oan elk beheind programma dat dat bestân lûkt, en profylen nei klachte-modus sette ferberget de folgjende wegering ynstee fan dizze op te lossen. De profylregel hellet in beliedswegering fuort; hy makket gjin privileezje, dus in proses dat nea CAP_SYS_CHROOT yn syn effektive set hie, sil noch mislearje mei de regel yn plak.

As it auditrecord hielendal gjin AppArmor-wegering sjen lit, stop dan mei it bewurkjen fan it profyl. Jo sjogge in legitimearringsprobleem, en it oerbleaune wurk is yn it unit-bestân of yn it memproses, net yn 'e beliedztaal.

De tsjinstbehearder hâldt syn eigen plafond

systemd set foar elke tsjinst in grinsset foar fermogens, en standert is dat set smel. Alles wat dêr útsletten is, is net beskikber foar it proses wat it profyl ek seit, dêrom kinne hurde units mislearje op in begearing dy't wurke doe't de daemon mei de hân starten waard. De relevante rjochtlinen binne maklik te lêzen yn 'e unit en maklik te ferjitten as de applikaasje de flater rapportearret. Drop-ins dy't in distribúsjepakket leveret binne de gewoane boarne fan in plafond dat nimmen betinkt dat er it konfigurearre hat.

It plafond ferheegje en it fermogen jaan binne twa wizigings, net ien. In record yn it grinsset seit dat it proses it fermogen hâlde mei; it foeget it net ta oan 'e effektive set, en NoNewPrivs kin in lettere ferheging tsjinhâlde slagje te litten sels as alles oars oerin komt. Foegje allinnich ta wat de begearing nedich hat, hâld de rest fan 'e ferhurding yntakt, en wjerstean de koarte wei om alle fermogens te jaan sadat ien oprop trochgiet.

De folchoarder is hjir ek fan belang. Feroarje earst it plafond fan 'e unit, kontrolearje dat CapEff no it bit befettet, en beslute dan pas oft AppArmor noch wegeret. Beide wizigings tagelyk dwaan lit jo wer riede as de flater oanhâldt.

As de wegering fuort is, kontrolearje de finzenis sels

In slagge chroot ferpleatst de woartel, dat elk paad dat de daemon dêrnei oanreitset wurdt yn 'e nije beam oplost. Ûntbrekkende konfiguraasje, in ûntbrekkend apparaatknooppunt of in sertifikaatmap dy't net kopiearre waard, sille no as in bestânsflater ferskine, en dy flater is in yndielingsprobleem, net in fermogensprobleem. Lês de folgjende barren ynstee fan noch in brede tastimming ta te foegjen. De ferpleatsing feroaret ek wat in relative paad betsjut, dêrom steane ferhurdingsgidsen op absolute paden yn 'e daemonkonfiguraasje.

It helpt ek om te betinken wat chroot net docht. It is in paadgrins, gjin sânbak: in proses dat it privileezje hâldt kin derút ûntkomme, dêrom wurdt it fermogen normaal nei de oprop falle litten en dêrom moat de beheining om de daemon hinne bliuwe. It AppArmor-profyl, it grinsset foar fermogens en de bestânssysteembeheiningen tegearre hâlde is it punt fan 'e oefening, net in oerbliuwsel om fuort te heljen sadra't de tsjinst start.

De beslissingsregel is koart. As it auditrecord AppArmor neamt, foegje ien fermogensregel ta oan it oanheakke profyl. As de effektive set leech is, reparearje it plafond fan 'e unit en de folchoarder fan privileezje falle litten. As it profyl net is dat jo bewurke, stop mei bewurkjen en fyn it echte.