Miks VPN-sertifikaadi teisaldamine rikub selle SELinux-sildi

Sertifikaadid võivad asuda õiges kataloogis loetava režiimi ja root-omandiga ning teenus võib ikkagi teatada, et ei saa faili avada. SELinux-süsteemis viitab see kombinatsioon ühele konkreetsele mehhanismile, mitte õigustele. Silt rändas koos failiga, sest ümbernimetamine ei loo uut objekti. Inode säilitas turbekonteksti, mis tal vanal teel oli, ja uue tee poliitika ei saanud kunagi võimalust määrata omaenda konteksti.

Mida ümbernimetamine tegelikult sildiga teeb

Fail kannab oma SELinux-konteksti inode’i külge kinnitatud atribuudiandmetena. Ümbernimetamine ühe failisüsteemi sees muudab kataloogikirjet ja mitte midagi muud, mis on kiire ja aatomiline, ning põhjus, miks kontekst teisaldamise üle elab. Ühtegi poliitikat ei küsitleta, ühtegi vaikeväärtust ei rakendata ja ühtegi hoiatust ei trükita.

Kopeerimine käitub teisiti. Koopia loob sihtkataloogis uue inode’i ja poliitika määrab konteksti selle kataloogi tüübi järgi, nii et kopeeritud sertifikaat saab tavaliselt õige sildi, samas kui teisaldatu jääb valeks. See üks erinevus seletab suuremat osa segadusest seda tüüpi piletites.

Failisüsteemidevahelised teisaldamised langesid tagasi kopeerimissemantikale, nii et sama käsk võib kahes masinas käituda erinevalt, sõltuvalt sellest, kas /etc asub omaette köitel. Kontrollige seda, enne kui järeldate, et tööriist on ebausaldusväärne. Üks pilk mount-tabelisse ütleb teile, millist tüüpi teisaldamise te tegite.

Lugege praegust silti oodatava vastu

Kolm ainult lugemiseks mõeldud käsku vastavad küsimusele ilma midagi muutmata. Esimene näitab, mis failil praegu on, teine teatab, mida poliitika täpselt selle tee jaoks ootab, ja kolmas loetleb iga faili kataloogi all, mille silt erineb.

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

Usaldada tasub proovijooksu, sest see nimetab iga faili, mille kontekst poliitikast kõrvale kaldub, ja jätab süsteemi siiski puutumata. Kui sertifikaat selles loendis ilmub, olete leidnud lahknevuse selle vahel, mida tee tähendab, ja selle vahel, mida fail väidab. Kui see ei ilmu, on silt juba see, mida poliitika tahab, ja teie aeg kuulub mujale.

Seejärel korreleerige erinevus tegeliku keeldumisega. Sobimatus on tõend vale sildi kohta, mitte tõestus, et teenus selle tõttu ebaõnnestus, ja parandus, mis on rakendatud ilma vastava keeldumiseta logis, on oletus lisasammudega.

Taastage vastendus, selle asemel et erand välja mõelda

Tavapärase asukoha puhul vastendab poliitika tee juba, nii et restorecon rakendab selle ja töö on tehtud. Hoidke ulatus kataloogil, mida parandate; kogu failisüsteemi ümbersildistamine on aeglane, häiriv ja matab algse vea väga suure muudatuse alla.

Kohandatud kataloogi puhul loeb järjekord ja selle ümberpööramine annab käsu, mis teatab edust, muutmata midagi. Vastendus kuulub poliitikasse, ümbersildistamine kuulub lõppu ja proovijooks kuulub mõlema ette. Viimase osa vahelejätmine on viis, kuidas tee, mis kunagi vale ei olnud, ikkagi ümbersildistatakse.

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

restorecon rakendab vastendust; see ei saa seda välja mõelda. Kui ükski reegel teed ei kirjelda, pole millestki taastada, mistõttu püsiv vastendus peab eksisteerima enne ümbersildistamist. Märkige üles, milline konfiguratsioon selle vastenduse omanik on, sest muidu loob hilisem teisaldamine, paketi uuendus või ümbersildistamine vea uuesti ja järgmine inimene alustab nullist.

Miks chcon ei ole lahendus

chcon kirjutab konteksti otse failile. See mõjub kohe ja on kõige vähem püsiv saadaolev valik, sest failisüsteemi ümbersildistamine rakendab poliitika uuesti ja heidab käsitsi tehtud muudatused küsimata kõrvale. Fail näeb parandatud välja ja parandusel on aegumiskuupäev, mida keegi kirja ei pannud. Selle asemel soovite reeglit, mis kirjeldab teed, et iga sinna jõudev fail saaks automaatselt sama kohtlemise.

Veel hullem, see õpetab vale õppetunni: alusvastendus on endiselt puudu, nii et rike naaseb nädalaid hiljem ilma ilmse päästikuta ja ilma mälestust möödasõidust. Kasutage chcon ainult ajutise katsena hüpoteesi kinnitamiseks, seejärel asendage see vastendusega, mis elab üle järgmise ümbersildistamise, ja kontrollige, et asendus on tõesti paigas.

Kui silt on õige ja juurdepääs ikka ebaõnnestub

Alustage ülemkataloogidest. Läbimisõigust kontrollitakse tee igal komponendil, nii et õigesti sildistatud sertifikaat kataloogis, kuhu teenus ei pääse, jääb ikkagi loetamatuks. Nii SELinux kui ka tavaline õigus peavad iga sammu lubama, ja ühe parandamine ei paranda teist.

Seejärel kontrollige protsessi identiteeti ja teenuse enda liivakasti. Piirava liivakastiga üksus võib keelata juurdepääsu failile, mille poliitika hea meelega lubaks, ja logirealt näevad kaks põhjust ühesugused välja. Kinnitage, milline protsess tegelikult küsib, mitte milline teie arvates küsib.

Pidage meeles, et dontaudit reeglid võivad keeldumisteateid maha suruda, nii et tühi auditilogi on nõrk tõend, mitte tõestus. Kui poliitika näeb õige välja ja juurdepääs ikka ebaõnnestub, uurige enne laia lubamismooduli genereerimist ja ärge lülitage SELinuxi välja, et sümptom kaoks. Mõlemad otseteed annavad süsteemi, mis näib töötavat, ja turvahoiaku, mida keegi kirjeldada ei oska. Lühike uurimine on parem kui kumbki neist.