Kial movo de VPN-atestilo rompas ĝian SELinux-etikedon

Atestiloj povas sidi en la ĝusta dosierujo kun legebla reĝimo kaj root-posedo, kaj la servo tamen povas raporti, ke ĝi ne povas malfermi la dosieron. Sur SELinux-sistemo tiu kombinaĵo indikas unu specifan mekanismon anstataŭ permesojn. La etikedo vojaĝis kun la dosiero, ĉar renomado ne kreas novan objekton. La inodo konservis la sekurecan kuntekston, kiun ĝi havis ĉe la malnova vojo, kaj la politiko por la nova vojo neniam ricevis la ŝancon atribui sian propran.

Kion renomado efektive faras al etikedo

Dosiero portas sian SELinux-kuntekston kiel atributajn datumojn ligitajn al la inodo. Renomado ene de unu dosiersistemo ŝanĝas la dosierujan enskribon kaj nenion alian, kio estas rapida kaj atoma, kaj estas la kialo, ke la kunteksto postvivas la movon. Neniu politiko estas konsultata, neniu defaŭlto estas aplikata, kaj neniu averto estas presata.

Kopiado kondutas alie. Kopio kreas novan inodon en la cela dosierujo, kaj la politiko atribuas kuntekston laŭ la tipo de tiu dosierujo, do kopiita atestilo kutime finiĝas kun ĝusta etikedo, dum movita restas malĝusta. Tiu sola diferenco klarigas la plejparton de la konfuzo en ĉi tiu klaso de biletoj.

Movoj inter dosiersistemoj falas reen al kopi-semantiko, do la sama komando povas konduti malsame sur du maŝinoj depende de tio, ĉu /etc loĝas sur propra volumo. Kontrolu tion antaŭ ol konkludi, ke la ilo estas nefidinda. Unu rigardo al la muntotabelo diras al vi, kian specon de movo vi faris.

Legu la nunan etikedon kontraŭ la atendata

Tri nurlegaj komandoj respondas la demandon sen ŝanĝi ion. La unua montras, kion la dosiero nun havas, la dua raportas, kion la politiko atendas por ĝuste tiu vojo, kaj la tria listigas ĉiun dosieron sub la dosierujo, kies etikedo diferencas.

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

La seka rulo estas tiu, kiun oni fidu, ĉar ĝi nomas ĉiun dosieron, kies kunteksto deflankiĝas de la politiko, kaj tamen lasas la sistemon netuŝita. Se la atestilo aperas en tiu listo, vi trovis la malkongruon inter tio, kion la vojo signifas, kaj tio, kion la dosiero asertas. Se ĝi ne aperas, la etikedo jam estas tio, kion la politiko volas, kaj via tempo apartenas aliloke.

Poste korelaciu la diferencon kun fakta rifuzo. Malkongruo estas pruvo de malĝusta etikedo, ne pruvo, ke la servo malsukcesis pro ĝi, kaj riparo aplikita sen responda rifuzo en la protokolo estas konjekto kun pliaj paŝoj.

Restarigu la mapadon anstataŭ elpensi escepton

Por norma loko la politiko jam mapas la vojon, do restorecon aplikas ĝin kaj la laboro finiĝis. Tenu la amplekson al la dosierujo, kiun vi riparas; reetikedi la tutan dosiersistemon estas malrapida, ĝena, kaj ĝi enterigas la originan eraron sub tre granda ŝanĝo.

Por propra dosierujo la ordo gravas, kaj inversigi ĝin produktas komandon, kiu raportas sukceson dum ŝanĝas nenion. La mapado apartenas al la politiko, la reetikedado apartenas al la fino, kaj la seka rulo apartenas antaŭ ambaŭ. Preterlasi tiun lastan parton estas la maniero, kiel vojo, kiu neniam estis malĝusta, tamen reetikedatas.

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon aplikas mapadon; ĝi ne povas elpensi unu. Se neniu regulo priskribas la vojon, estas nenio por restarigi, do la daŭra mapado devas ekzisti antaŭ la reetikedado. Notu, kiu agordo posedas tiun mapadon, ĉar alie posta movo, pakaĵa ĝisdatigo aŭ reetikedado rekreas la fuŝaĵon kaj la sekva persono komencas de nulo.

Kial chcon ne estas la solvo

chcon skribas kuntekston rekte sur la dosieron. Ĝi efikas tuj kaj estas la malplej daŭra disponebla opcio, ĉar reetikedado de dosiersistemo reaplikas la politikon kaj forĵetas manajn ŝanĝojn sen demandi. La dosiero aspektas riparita kaj la riparo havas findaton, kiun neniu skribis. Kion vi anstataŭe volas, estas regulo priskribanta la vojon, por ke ĉiu dosiero alvenanta tien aŭtomate ricevu la saman traktadon.

Pli malbone, ĝi instruas la malĝustan lecionon: la suba mapado ankoraŭ mankas, do la fuŝaĵo revenas semajnojn poste sen evidenta kaŭzilo kaj sen memoro pri la provizora solvo. Uzu chcon nur kiel provizoran eksperimenton por konfirmi hipotezon, poste anstataŭigu ĝin per mapado, kiu postvivas la sekvan reetikedadon, kaj kontrolu, ke la anstataŭaĵo efektive estas surloke.

Kiam la etikedo estas ĝusta kaj aliro tamen malsukcesas

Komencu per la gepatraj dosierujoj. Trapasa permeso estas kontrolata ĉe ĉiu komponanto de la vojo, do ĝuste etikedita atestilo en dosierujo, en kiun la servo ne povas eniri, restas nelegebla. Kaj SELinux kaj ordinara permeso devas permesi ĉiun paŝon, kaj ripari unu ne riparas la alian.

Poste kontrolu la procezan identecon kaj la propran sabloskatolon de la servo. Unuo kun restrikta sabloskatolo povas rifuzi aliron al dosiero, kiun la politiko volonte permesas, kaj laŭ la protokola linio la du kaŭzoj aspektas identaj. Konfirmu, kiu procezo efektive demandas, ne kiun vi supozas demandanta.

Memoru, ke reguloj dontaudit povas subpremi rifuzajn mesaĝojn, do malplena aŭdita protokolo estas malforta pruvo anstataŭ pruvo. Se la politiko aspektas ĝusta kaj aliro tamen malsukcesas, esploru antaŭ ol generi vastan permesan modulon, kaj ne malŝaltu SELinux por igi la simptomon malaperi. Ambaŭ mallongigoj produktas sistemon, kiu ŝajnas funkcii, kaj sekurecan pozicion, kiun neniu povas priskribi. Mallonga esploro superas ambaŭ.