chroot-ek huts egiten du OpenVPN-n: AppArmor araua edo gaitasuna?
AppArmor profilean bide bat gehitzeak ez du inoiz CAP_SYS_CHROOT ematen, eta ukatu den chroot hiru geruza desberdinetatik etor daiteke. Erabaki zein aldatu.
Daemonak chroot huts bat erregistratzen du eta profila jada zabala dirudi, beraz, konponbide tentagarria bide-arau bat zabaltzea eta berrabiaraztea da. Horrek normalean ez du ezer aldatzen, chroot profileak inoiz eman ezin izan zuen pribilegio batek kontrolatzen baitu. Zein geruza ukitu erabakitzeko hiru egiaztapen egin behar dira, eta merkeak dira: prozesuak zer eduki dezakeen, politikak zer baimentzen duen, eta abiarazleak zer kendu zuen horietako edozeinek axola baino lehen.
Bi ate bereizi, eta bakarra da AppArmor-ena
chroot-ek CAP_SYS_CHROOT behar du prozesua exekutatzen ari den erabiltzaile-espazioaren izen-espazioan. Linux pribilegio arrunta da, kernelak deiak bideekin ezer egin baino lehen egiaztatzen duena. Bereizita, AppArmor profil betearazle batek gaitasuna uka dezake prozesuak daukan arren, politika derrigorrezkoa kredentzialekin batera kontsultatzen delako, haien ordez eta haien gainean. Bereizketa garrantzitsua da praktikan: bi geruzak fitxategi desberdinetan bizi dira eta normalean pertsona desberdinek mantentzen dituzte.
Bi ate horiek errno berarekin huts egiten dute. Biek EPERM sortzen dute, eta biek baimen-kexa orokor gisa agertzen dira daemonaren erregistroan, eta horregatik profilaren edukia asmatzeak hainbeste denbora galtzen du. Gehituko zenuen bide-arauak chroot ondo atera ondoren fitxategi-sarbidea kontrolatzen du; ez du zerikusirik eragiketa baimenduta dagoen ala ez.
Hirugarren ate bat bien gainetik dago. Zerbitzu-kudeatzaileak edo bilgarri batek prozesua bere muga-multzoan gaitasuna gabe abiarazi bazuen, AppArmor-en aldaketak ezin du berreskuratu, eta profilean gaitasunak gehitzeak kernelak ez duen asmoa dokumentatzen du soilik.
Irakurri pribilegio-egoera politika editatu aurretik
Hasi martxan dagoen prozesutik, aktibo uste duzun konfiguraziotik beharrean. Egoera-fitxategiak bost gaitasun-maskara eta no-new-privileges bandera erakusten ditu, eta galdera desberdinei erantzuten diete:
grep -E '^(CapInh|CapPrm|CapEff|CapBnd|CapAmb|NoNewPrivs):' /proc/$(pidof openvpn)/status
sudo aa-status | grep -i openvpnCapEff da deirako garrantzitsua den multzoa: CapBnd-n dagoen baina CapEff-n ez dagoen gaitasuna sabailek baimentzen du eta unean ez da edukitzen. CapAmb garrantzitsua da binarioa setuid zentzu arruntean pribilegiatuta ez dagoenean, gaitasun girokoak baitira zerbitzu batek exec zehar pribilegioa fitxategi-gaitasunik gabe mantentzeko duen modua. CapInh-ek exec zehar hereda daitezkeen bitak ditu, baina exekutatutako fitxategiaren multzo heredegarriak baimentzen duenean soilik, beraz hango bit batek ez du ezer ematen bere kasa.
Ondoren egiaztatu zein profil dagoen benetan atxikita. Prozesua espero ez zenuen profil-izen batek mugatua egon daiteke, batez ere banaketa batek bere unitate-fitxategia eta profila elkarrekin banatzen dituenean, eta /proc/PID/attr/current irakurtzeak hori lerro bakarrean argitzen du. Zure fitxategi editatua kernelak ematen duen profilarekin alderatzea kausa konpontzearen eta inork kargatzen ez duen fitxategi bat editatzearen arteko aldea da.
Gehitu gaitasun-araua soilik auditoria-arrastoak hala dioenean
Kernelaren eta auditoriaren erregistroek ukatzen duen geruzari izena ematen diote. Bilatu capable eragiketarekin eta sys_chroot izenarekin datorren ukazio bat, sortu zuen profilarekin batera. Erregistro hori badago, prozesuak gaitasuna jada zeukan eta AppArmor-ek ukatu zion, eta aldaketa zuzena profil errealean gaitasun-arau bat da:
capability sys_chroot,Mantendu zatiki gisa benetan atxikita dagoen profilean, eta egiaztatu gako-hitza apparmor.d profilaren erreferentziaren aurka, araua erlaziorik gabeko tutorial batetik kopiatu beharrean. Partekatutako include batean sartzeak fitxategi hori hartzen duen programa mugatu guztiei ematen die, eta profilak complain modura aldatzeak hurrengo ukazioa ezkutatzen du, hau konpondu beharrean. Profil-arauak politika-ukazio bat kentzen du; ez du pribilegioa sortzen, beraz CAP_SYS_CHROOT inoiz bere multzo eraginkorrean izan ez duen prozesuak huts egingo du araua jarrita ere.
Auditoria-erregistroak AppArmor ukaziorik bat ere erakusten ez badu, utzi profila editatzen. Kredentzialen arazo bati aurre egiten ari zara, eta gainerako lana unitate-fitxategian edo guraso-prozesuan dago, ez politika-hizkuntzan.
Zerbitzu-kudeatzaileak bere sabaia mantentzen du
systemd-k gaitasun muga-multzo bat ezartzen du zerbitzu bakoitzeko, eta lehenespenez multzo hori estua da. Han baztertutakoa ez dago prozesuarentzat eskuragarri, profilak zer esan nahi duen ere, eta horregatik unitate gogortuek huts egiten dute daemona eskuz abiarazita funtzionatzen zuen eragiketa batean. Direktiba esanguratsuak erraz irakurtzen dira unitatean eta erraz ahazten dira aplikazioak hutsegitea jakinarazten duenean. Banaketa-paketeek hornitutako drop-inek dira inork gogoratzen ez duen sabai baten ohiko iturria.
Sabaia igotzea eta gaitasuna ematea bi aldaketa dira, ez bat. Muga-multzoaren sarrera batek prozesuak gaitasuna eduki dezakeela dio; ez dio multzo eraginkorrari gehitzen, eta NoNewPrivs-ek geroagoko goratze bat oztopa dezake gainerako guztia bat datorrenean ere. Gehitu eragiketak behar duena soilik, mantendu gainerako gogortasuna, eta baztertu dei bat pasatzeko gaitasun guztiak emateko lasterbidea.
Ordenak ere garrantzia du hemen. Aldatu unitatearen sabaia lehenik, egiaztatu CapEff-ek bita orain duela, eta gero erabaki AppArmor-ek ukatzen duen ala ez. Bi aldaketak aldi berean egiteak berriro asmatzera behartzen zaitu porrotak jarraitzen badu.
Ukazioa garbitu ondoren, egiaztatu kartzela bera
chroot ondo ateratzen bada erroa mugitzen du, beraz daemonak gero ukitzen duen bide guztiak zuhaitz berrian ebazten dira. Konfigurazio falta, gailu-nodo bat ausentea edo kopiatu ez zen ziurtagiri-direktorio bat fitxategi-errore gisa agertuko dira orain, eta errore hori diseinu-arazo bat da, ez gaitasun-arazo bat. Irakurri hurrengo gertaera, beste baimen zabal bat gehitu beharrean. Mugimenduak bide erlatibo batek duen esanahia ere aldatzen du, eta horregatik gogortze-gidek bide absolutuak eskatzen dituzte daemonaren konfigurazioan.
Gogoratzen laguntzen du chroot-ek zer egiten ez duen. Bide-muga bat da, ez sandbox bat: pribilegioa mantentzen duen prozesu batek ihes egin dezake, eta horregatik gaitasuna normalean deia egin ondoren uzten da eta horregatik konfinamenduak daemonaren inguruan jarraitu behar du. AppArmor profila, gaitasun muga-multzoa eta fitxategi-sistemen murrizketak elkarrekin mantentzea da ariketa honen helburua, ez zerbitzua abiarazten denean kentzeko soberakin bat.
Erabaki-araua laburra da. Auditoria-erregistroak AppArmor aipatzen badu, gehitu gaitasun-arau bat atxikitako profilari. Multzo eraginkorra hutsik badago, konpondu unitatearen sabaia eta pribilegioa uzteko ordena. Profila editatu duzuna ez bada, utzi editatzen eta aurkitu benetakoa.