Miksi VPN-varmenteen siirtäminen rikkoo sen SELinux-tunnisteen

Varmenteet voivat olla oikeassa hakemistossa luettavalla tilalla ja root-omistuksella, ja palvelu voi silti ilmoittaa, ettei se voi avata tiedostoa. SELinux-järjestelmässä tämä yhdistelmä viittaa yhteen tiettyyn mekanismiin eikä käyttöoikeuksiin. Tunniste matkasi tiedoston mukana, koska uudelleennimeäminen ei luo uutta objektia. Inode säilytti sen turvakontekstin, joka sillä oli vanhassa polussa, eikä uuden polun käytäntö koskaan saanut tilaisuutta määrittää omaansa.

Mitä uudelleennimeäminen oikeastaan tekee tunnisteelle

Tiedosto kantaa SELinux-kontekstinsa inodeen liitettyinä attribuuttitietoina. Uudelleennimeäminen yhden tiedostojärjestelmän sisällä muuttaa hakemistomerkintää eikä mitään muuta, mikä on nopeaa ja atomaarista, ja syy siihen, että konteksti selviää siirrosta. Mitään käytäntöä ei kysytä, mitään oletusta ei sovelleta eikä mitään varoitusta tulosteta.

Kopiointi käyttäytyy toisin. Kopio luo uuden inoden kohdehakemistoon, ja käytäntö määrittää kontekstin kyseisen hakemiston tyypistä, joten kopioitu varmenne päätyy yleensä oikeaan tunnisteeseen, kun taas siirretty jää vääräksi. Juuri tämä yksi ero selittää suurimman osan tämän luokan tikettien sekaannuksesta.

Tiedostojärjestelmien väliset siirrot palaavat kopioinnin semantiikkaan, joten sama komento voi käyttäytyä eri tavoin kahdella koneella riippuen siitä, onko /etc omalla taltiollaan. Tarkista tämä ennen kuin päättelet työkalun olevan epäluotettava. Yksi silmäys liitostaulukkoon kertoo, millaisen siirron teit.

Lue nykyinen tunniste odotettua vastaan

Kolme vain luku -komentoa vastaavat kysymykseen muuttamatta mitään. Ensimmäinen näyttää, mitä tiedostolla on nyt, toinen ilmoittaa, mitä käytäntö odottaa juuri tälle polulle, ja kolmas luettelee jokaisen hakemiston alla olevan tiedoston, jonka tunniste poikkeaa.

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

Kokeiluajo on se, johon kannattaa luottaa, koska se nimeää jokaisen tiedoston, jonka konteksti poikkeaa käytännöstä, ja jättää järjestelmän silti koskemattomaksi. Jos varmenne näkyy sillä listalla, olet löytänyt ristiriidan sen välillä, mitä polku tarkoittaa, ja sen välillä, mitä tiedosto väittää. Jos se ei näy, tunniste on jo se, mitä käytäntö haluaa, ja aikasi kuuluu muualle.

Korreloi sitten ero todelliseen kieltäytymiseen. Epäjohdonmukaisuus on todiste väärästä tunnisteesta, ei todiste siitä, että palvelu epäonnistui sen vuoksi, ja korjaus, joka tehdään ilman vastaavaa kieltäytymistä lokissa, on arvaus ylimääräisillä vaiheilla.

Palauta kuvaus sen sijaan että keksit poikkeuksen

Vakiopaikalle käytäntö kuvaa polun jo, joten restorecon soveltaa sen ja työ on tehty. Pidä laajuus hakemistossa, jota korjaat; koko tiedostojärjestelmän uudelleenmerkintä on hidasta, häiritsevää, ja se hautaa alkuperäisen virheen erittäin suuren muutoksen alle.

Mukautetun hakemiston kohdalla järjestys ratkaisee, ja sen kääntäminen tuottaa komennon, joka ilmoittaa onnistumisesta muuttamatta mitään. Kuvaus kuuluu käytäntöön, uudelleenmerkintä kuuluu loppuun ja kokeiluajo kuuluu ennen molempia. Tuon viimeisen osan väliin jättäminen on se tapa, jolla polku, joka ei koskaan ollut väärä, silti merkitään uudelleen.

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

restorecon soveltaa kuvausta; se ei voi keksiä sellaista. Jos mikään sääntö ei kuvaa polkua, ei ole mitään palautettavaa, minkä vuoksi pysyvän kuvauksen on oltava olemassa ennen uudelleenmerkintää. Kirjaa, mikä kokoonpano omistaa kyseisen kuvauksen, koska muuten myöhempi siirto, pakettipäivitys tai uudelleenmerkintä luo vian uudelleen ja seuraava henkilö aloittaa nollasta.

Miksi chcon ei ole ratkaisu

chcon kirjoittaa kontekstin suoraan tiedostoon. Se vaikuttaa heti ja on vähiten kestävä saatavilla oleva vaihtoehto, koska tiedostojärjestelmän uudelleenmerkintä soveltaa käytännön uudelleen ja heittää manuaaliset muutokset pois kysymättä. Tiedosto näyttää korjatulta ja korjauksella on vanhenemispäivä, jota kukaan ei kirjoittanut. Sen sijaan haluat säännön, joka kuvaa polun, jotta jokainen sinne saapuva tiedosto saa automaattisesti saman kohtelun.

Pahempaa, se opettaa väärän opetuksen: taustalla oleva kuvaus puuttuu edelleen, joten vika palaa viikkoja myöhemmin ilman ilmeistä laukaisinta ja ilman muistoa kierrosta. Käytä chcon vain väliaikaisena kokeena hypoteesin vahvistamiseen, korvaa se sitten kuvauksella, joka kestää seuraavan uudelleenmerkinnän, ja tarkista, että korvaava on todella paikallaan.

Kun tunniste on oikein ja pääsy epäonnistuu silti

Aloita ylähakemistoista. Läpikulkulupa tarkistetaan polun jokaiselta osalta, joten oikein merkitty varmenne hakemistossa, johon palvelu ei pääse, on edelleen lukukelvoton. Sekä SELinuxin että tavallisen luvan on sallittava jokainen askel, eikä toisen korjaaminen korjaa toista.

Tarkista sitten prosessin identiteetti ja palvelun oma hiekkalaatikko. Yksikkö, jolla on rajoittava hiekkalaatikko, voi kieltää pääsyn tiedostoon, jonka käytäntö mielellään sallisi, ja lokiriviltä molemmat syyt näyttävät samoilta. Vahvista, mikä prosessi todella kysyy, älä sitä, minkä oletat kysyvän.

Muista, että dontaudit-säännöt voivat vaimentaa kieltäytymisviestejä, joten tyhjä audit-loki on heikko todiste eikä todiste. Jos käytäntö näyttää oikealta ja pääsy epäonnistuu silti, tutki ennen laajan sallintamoduulin luomista, äläkä poista SELinuxia käytöstä oireen hävittämiseksi. Molemmat oikotiet tuottavat järjestelmän, joka näyttää toimivan, ja turva-asennon, jota kukaan ei osaa kuvata. Lyhyt tutkimus voittaa kumman tahansa.