chroot malsukcesas en OpenVPN: ĉu regulo de AppArmor aŭ kapablo?

La demono enskribas malsukceson de chroot kaj la profilo jam aspektas malavara, do la alloga ripeto estas larĝigi vojan regulon kaj restartigi. Tio kutime ŝanĝas nenion, ĉar chroot estas gardata de privilegio, kiun la profilo neniam povis transdoni. Decidi, kiun tavolon tuŝi, postulas tri kontrolojn, kaj ili estas malmultekostaj: kion la procezo rajtas teni, kion la politiko permesas, kaj kion la lanĉilo forigis antaŭ ol iu el la du gravis.

Du apartaj pordegoj, kaj nur unu apartenas al AppArmor

chroot bezonas CAP_SYS_CHROOT en la uzant-nomspaco, en kiu la procezo ruliĝas. Tio estas ordinara Linuksa privilegio, kaj la kerno kontrolas ĝin antaŭ ol la voko faras ion ajn kun vojoj. Aparte, plenuma AppArmor-profilo povas rifuzi la kapablon eĉ kiam la procezo posedas ĝin, ĉar deviga politiko estas konsultata aldoniĝe al la legitimiloj, ne anstataŭ ili. La distingo gravas en praktiko: la du tavoloj loĝas en malsamaj dosieroj kaj kutime prizorgatas de malsamaj homoj.

Ambaŭ pordegoj malsukcesas kun la sama errno. Ambaŭ produktas EPERM, kaj ambaŭ aperas kiel ĝenerala permesa plendo en la demona protokolo, kaj tial divenado pri la profila enhavo perdas tiom da tempo. La voja regulo, kiun vi estis aldononta, regas dosieran aliron post kiam chroot sukcesis; ĝi neniel rilatas al tio, ĉu la operacio entute permesatas.

Tria pordego staras super ambaŭ. Se la servadministranto aŭ envolvaĵo lanĉis la procezon sen la kapablo en ĝia limiga aro, neniu AppArmor-ŝanĝo povas redoni ĝin, kaj aldoni kapablojn al la profilo nur dokumentas intencon, kiun la kerno ne honoros.

Legu la privilegian staton antaŭ ol redakti la politikon

Komencu de la kuranta procezo, ne de la agordo, kiun vi kredas aktiva. La statodosiero montras kvin kapablomaskojn kaj la flagon no-new-privileges, kaj ili respondas al malsamaj demandoj:

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

CapEff estas la aro grava por la voko: kapablo ĉeestanta en CapBnd sed forestanta el CapEff permesatas de la plafono kaj nuntempe ne tenatas. CapAmb gravas kiam la binara dosiero ne estas privilegia laŭ la kutima setuid-senco, ĉar ĉirkaŭaj kapabloj estas la maniero, kiel servo konservas privilegion tra exec sen dosieraj kapabloj. CapInh tenas bitojn heredeblajn tra exec, sed nur kiam la heredebla aro de la plenumata dosiero permesas tion, do bito tie per si mem donas nenion.

Poste konfirmu, kiu profilo estas fakte alligita. Procezo povas esti limigita per profila nomo, kiun vi ne atendis, precipe kiam distribuo liveras sian unuan dosieron kaj profilon kune, kaj legado de /proc/PID/attr/current solvas tion en unu linio. Kompari vian redaktitan dosieron kun la profilo, kiun la kerno raportas, estas la diferenco inter ripari la kaŭzon kaj redakti dosieron, kiun neniu ŝargas.

Aldonu la kapabloregulon nur kiam la revizia spuro tion diras

Kernaj kaj reviziaj rikordoj nomas la rifuzantan tavolon. Serĉu rifuzon, kiu portas la operacion capable kaj la nomon sys_chroot, kune kun la profilo, kiu ĝin produktis. Se tia rikordo ekzistas, la procezo jam tenis la kapablon kaj AppArmor rifuzis ĝin, kaj la celita ŝanĝo estas kapabloregulo ene de la reala profilo:

capability sys_chroot,

Tenu ĝin kiel fragmento en la profilo, kiu vere estas alligita, kaj kontrolu la ŝlosilvorton laŭ la referenco pri apparmor.d-profiloj anstataŭ kopii regulon el nierilata lernilo. Meti ĝin en komunan include donas ĝin al ĉiu limigita programo, kiu tiras tiun dosieron, kaj ŝanĝi profilojn al plenda reĝimo kaŝas la sekvan rifuzon anstataŭ solvi ĉi tiun. La profila regulo forigas politikan rifuzon; ĝi ne kreas privilegion, do procezo, kiu neniam havis CAP_SYS_CHROOT en sia efika aro, ankoraŭ malsukcesos kun la regulo en loko.

Se la revizia rikordo montras neniun AppArmor-rifuzon entute, ĉesu redakti la profilon. Vi vidas legitimilan problemon, kaj la restanta laboro estas en la unua dosiero aŭ en la patra procezo, ne en la politika lingvo.

La servadministranto tenas sian propran plafonon

systemd starigas limigan aron de kapabloj por ĉiu servo, kaj defaŭlte tiu aro estas mallarĝa. Ĉio ekskludita tie ne estas disponebla al la procezo, kion ajn diras la profilo, kaj tial harditaj unuoj povas malsukcesi en operacio, kiu funkciis kiam la demono lanĉiĝis mane. La koncernaj direktivoj estas facile legeblaj en la unuo kaj facile preteratenteblaj kiam la aplikaĵo raportas la eraron. Drop-in dosieroj liveritaj de distribua pako estas la kutima fonto de plafono, kiun neniu memoras agordi.

Levi la plafonon kaj doni la kapablon estas du ŝanĝoj, ne unu. Rikordo en la limiga aro diras, ke la procezo rajtas teni la kapablon; ĝi ne aldonas ĝin al la efika aro, kaj NoNewPrivs povas malhelpi postan altigon sukcesi eĉ kiam ĉio alia kongruas. Aldonu nur tion, kion la operacio bezonas, konservu la reston de la hardado senŝanĝa, kaj rezistu la mallongigon doni ĉiujn kapablojn por ke unu voko pasu.

Ankaŭ la ordo gravas ĉi tie. Unue ŝanĝu la plafonon de la unuo, kontrolu ke CapEff nun enhavas la biton, kaj nur poste decidu, ĉu AppArmor ankoraŭ rifuzas. Fari ambaŭ ŝanĝojn samtempe lasas vin denove diveni, se la malsukceso daŭras.

Kiam la rifuzo malaperis, kontrolu la kaĝon mem

Sukcesa chroot movas la radikon, do ĉiu vojo, kiun la demono poste tuŝas, estas solvata ene de la nova arbo. Mankanta agordo, forestanta aparata nodo aŭ certifika dosierujo, kiu ne estis kopiita, nun aperos kiel dosiera eraro, kaj tiu eraro estas aranĝa problemo, ne kapabla problemo. Legu la sekvan eventon anstataŭ aldoni ankoraŭ unu vastan permeson. La movo ankaŭ ŝanĝas, kion signifas relativa vojo, kaj tial hardadgvidiloj insistas pri absolutaj vojoj en la demona agordo.

Ankaŭ helpas memori, kion chroot ne faras. Ĝi estas voja limo, ne sablujo: procezo, kiu konservas la privilegion, povas eskapi el ĝi, kaj tial la kapablo kutime faligatas post la voko kaj tial la limigo devus resti ĉirkaŭ la demono. Teni la AppArmor-profilon, la limigan aron de kapabloj kaj la dosiersistemajn limigojn kune estas la senco de la ekzerco, ne restaĵo forigenda tuj kiam la servo ekfunkcias.

La decida regulo estas mallonga. Se la revizia rikordo nomas AppArmor, aldonu unu kapabloregulon al la alligita profilo. Se la efika aro estas malplena, riparu la plafonon de la unuo kaj la ordon de faligo de privilegioj. Se la profilo ne estas tiu, kiun vi redaktis, ĉesu redakti kaj trovu la realan.