Vi rulas la skripton up kiel radiko, ĝi finiĝas, kaj la sama skripto malsukcesas kiam la servo vokas ĝin. Nenio pri la dosieraj permesoj ŝanĝiĝis, do la natura sekva paŝo estas denove malstreĉi ilin, kio solvas nenion. Sur SELinux-gastiganto la decida faktoro ofte ne estas kiu estas la procezo, sed en kiu domajno ĝi ruliĝas, kaj radiko ene de limigita domajno restas limigita.

Sama komando, du malsamaj sekurecaj domajnoj

Tipa devigo taksas la fontan domajnon, la celan etikedon kaj la petitan operacion kune. Via terminala seanco ruliĝas en nelimigita aŭ administra domajno, kaj la demono ruliĝas en tiu domajno, kiu estas atribuinta al ĝia unuo. Identaj komandoj do produktas malsamajn decidojn, kaj la diferenco estas intenca prefere ol cimo en la politiko.

Tial komparado de la du ruladoj utilas nur se vi komparas iliajn kuntekstojn. Rulu la saman komandon el la ŝelo kaj el la hoko, kaj la ŝela versio pruvas, ke la binara dosiero ekzistas kaj la argumentoj estas ĝustaj; ĝi pruvas nenion pri tio, ĉu la servo rajtas plenumi ĝin. Rulu ĝin ambaŭmaniere kaj komparu la domajnojn, ne nur la elirajn kodojn. Ĝuste tiu komparo transformas malprecizan permesan plendon en specifan demandon pri unu domajno kaj unu etikedo.

La klasika formo de ĉi tiu paneo estas helpilo, kiu vokas eksteran ilon. La hoko mem povas esti permesita, dum la ilo, kiun ĝi vokas, portas etikedon, kiun la serva domajno ne rajtas plenumi, aŭ skribas en dosierujon, kies etikedo malpermesas tion.

Legu la AVC-rikordon apud la hoka eraro

AVC-rifuzo nomas la kampojn, kiuj decidas la kazon: la fonta kunteksto de la procezo, la cela kunteksto de la objekto, la objektklaso kaj la specifa permeso, kiu estis rifuzita. Legu ĉiujn kvar antaŭ ol formi teorion, ĉar rifuzo pri plenumo kaj rifuzo pri skribado havas tute malsamajn riparojn.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

La fonta kunteksto devus kongrui kun la domajno, en kiu la servo efektive ruliĝas, kaj la cela kunteksto kun la etikedo de la dosiero aŭ dosierujo, kiun la operacio tuŝis. Se iu el ili ne kongruas kun la eraro, kiun vi postsekvas, vi legas alian eventon.

Notu la politikan version kaj la precizan vojon de la plenumebla dosiero apud la rikordo. Domajna nomo, kiu aperas en la politiko de unu distribuo, estas pruvo pri tiu instalado, ne garantio, ke alia konstruo liveras la samajn regulojn. Ĝuste tiu kunteksto ebligas al iu alia reprodukti vian konkludon sur sia propra gastiganto. Sen ĝi la rikordo legiĝas kiel anekdoto prefere ol pruvo.

Etikedo, agordo aŭ politiko: tri riparoj

La unua riparo estas etikedo, kiu ne kongruas kun la instalita loko de la dosiero. Skripto kopiita sur sian lokon per cp aŭ skribita de redaktilo povas porti defaŭltan etikedon, kiun la serva domajno ne povas uzi, kaj restarigo de la atendita kunteksto solvas tion sen tuŝi la politikon entute.

La dua estas agordo. La distribuo eble ofertas subtenatan manieron plenumi la operacion, dokumentitan dosierujon por la helpilo aŭ ĝisdatigitan politikpakon, kiu jam permesas ĝin. Ŝanĝi vian aranĝon al la subtenata estas pli malmultekosta ol skribi politikon kaj supervivas ĝisdatigojn.

La tria estas vere mankanta regulo, kaj ĝi devus esti la lasta rimedo. Generu kandidaton per la aŭdaj iloj, legu, kion ĝi efektive permesas, mallarĝigu ĝin al la operacio kaj domajno, kiujn vi observis, kaj lasu iun alian revizii ĝin antaŭ ol ĝi proksimiĝos al produktaĵo.

Kial malnova permesa modulo ne estas la respondo

Serĉrezultoj por ĉi tiu paneo plenas je pretaj moduloj, ofte por ilo, kiun la hoko ne plu vokas. Instali unu donas permesojn, kiuj eble havas nenion komunan kun via rifuzo, kaj ĝi lasas la veran malkongruon en loko dum aldonas permanentan truon.

Ĝi ankaŭ kaŝas la sekvan malsukceson. Modulo, kiu permesas larĝan klason de operacioj, igos ĉi tiun eraron malaperi kaj transformos la sekvan en ion multe pli malfacile atribueblan. Forigi la modulon poste ankaŭ estas ŝanĝo, kiun neniu volas plani, do la fuĝvojo emas fariĝi permanenta.

La disciplinema komparo estas inter la rifuzo, kiun vi povas legi, kaj la ŝanĝo, kiun vi proponas. La gvidilo pri solvado de SELinux-problemoj de Red Hat metas etikedajn kaj agordajn kontrolojn antaŭ generita politiko ĝuste pro ĉi tiu kialo. Se en la rikordo mankas responda rifuzo, SELinux probable ne estas via problemo, kaj temoj pri vojo, sandbox aŭ permesoj ankoraŭ restas malfermitaj.

Rilataj artikoloj