Kodėl VPN sertifikato perkėlimas sugadina jo SELinux etiketę

Sertifikatai gali būti tinkamame kataloge su skaitomu režimu ir root nuosavybe, o paslauga vis tiek gali pranešti, kad negali atidaryti failo. SELinux sistemoje šis derinys nurodo vieną konkretų mechanizmą, o ne teises. Etiketė keliavo kartu su failu, nes pervadinimas nesukuria naujo objekto. Inode išlaikė saugumo kontekstą, kurį turėjo senajame kelyje, o naujojo kelio politika niekada negavo galimybės priskirti savo.

Ką pervadinimas iš tikrųjų daro etiketei

Failas savo SELinux kontekstą neša kaip atributo duomenis, prijungtus prie inode. Pervadinimas vienoje failų sistemoje pakeičia katalogo įrašą ir nieko daugiau, o tai greita ir atominė, ir tai priežastis, kodėl kontekstas išgyvena perkėlimą. Jokia politika nėra klausiama, jokia numatytoji reikšmė netaikoma ir joks įspėjimas nespausdinamas.

Kopijavimas elgiasi kitaip. Kopija sukuria naują inode paskirties kataloge, o politika priskiria kontekstą pagal to katalogo tipą, todėl nukopijuotas sertifikatas paprastai gauna teisingą etiketę, o perkeltasis lieka neteisingas. Būtent šis vienas skirtumas paaiškina didžiąją dalį painiavos šios rūšies bilietuose.

Perkėlimai tarp failų sistemų grįžta prie kopijavimo semantikos, todėl ta pati komanda gali elgtis skirtingai dviejose mašinose priklausomai nuo to, ar /etc yra savo atskirame tome. Patikrinkite tai prieš darydami išvadą, kad įrankis nepatikimas. Vienas žvilgsnis į prijungimo lentelę pasako, kokio tipo perkėlimą atlikote.

Perskaitykite dabartinę etiketę prieš laukiamą

Trys tik skaitymo komandos atsako į klausimą nieko nekeisdamos. Pirmoji rodo, ką failas turi dabar, antroji praneša, ko politika tikisi būtent tam keliui, o trečioji išvardija kiekvieną failą kataloge, kurio etiketė skiriasi.

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

Pasitikėti verta bandomuoju paleidimu, nes jis įvardija kiekvieną failą, kurio kontekstas nukrypsta nuo politikos, ir vis tiek palieka sistemą nepaliestą. Jei sertifikatas atsiranda tame sąraše, radote neatitikimą tarp to, ką kelias reiškia, ir to, ką failas teigia. Jei jis neatsiranda, etiketė jau yra tai, ko nori politika, ir jūsų laikas priklauso kitur.

Tada susiekite skirtumą su tikru atsisakymu. Neatitikimas yra neteisingos etiketės įrodymas, o ne įrodymas, kad paslauga dėl to nepavyko, o pataisymas, pritaikytas be atitinkamo atsisakymo žurnale, yra spėjimas su papildomais žingsniais.

Atkurkite susiejimą, o ne išgalvokite išimtį

Standartinei vietai politika jau susieja kelią, todėl restorecon pritaiko ją ir darbas baigtas. Laikykite apimtį kataloge, kurį taisote; visos failų sistemos peržymėjimas yra lėtas, trikdantis ir palaidoja pradinę klaidą po labai dideliu pakeitimu.

Pasirinktiniam katalogui tvarka svarbi, o ją apvertus gaunama komanda, kuri praneša apie sėkmę nieko nepakeisdama. Susiejimas priklauso politikai, peržymėjimas priklauso pabaigai, o bandomasis paleidimas priklauso prieš abu. To paskutinio etapo praleidimas yra būdas, kuriuo kelias, kuris niekada nebuvo neteisingas, vis tiek peržymimas.

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

restorecon pritaiko susiejimą; jis negali jo išgalvoti. Jei jokia taisyklė neaprašo kelio, nėra iš ko atkurti, todėl nuolatinis susiejimas turi egzistuoti prieš peržymėjimą. Užrašykite, kuri konfigūracija valdo tą susiejimą, nes kitu atveju vėlesnis perkėlimas, paketo atnaujinimas ar peržymėjimas vėl sukuria gedimą ir kitas žmogus pradeda nuo nulio.

Kodėl chcon nėra sprendimas

chcon įrašo kontekstą tiesiai į failą. Jis įsigalioja iš karto ir tai yra mažiausiai ilgaamžė galima parinktis, nes failų sistemos peržymėjimas iš naujo taiko politiką ir atmeta rankinius pakeitimus nepaklausęs. Failas atrodo pataisytas, o pataisymas turi galiojimo datą, kurios niekas neužrašė. Vietoj to jums reikia taisyklės, aprašančios kelią, kad kiekvienas ten atvykstantis failas automatiškai gautų tą patį apdorojimą.

Dar blogiau, tai moko neteisingos pamokos: pagrindinio susiejimo vis dar nėra, todėl gedimas grįžta po kelių savaičių be akivaizdaus trigerio ir be atminties apie tą apeinamąjį sprendimą. Naudokite chcon tik kaip laikiną eksperimentą hipotezei patvirtinti, tada pakeiskite jį susiejimu, kuris išgyvena kitą peržymėjimą, ir patikrinkite, ar pakaitalas tikrai yra vietoje.

Kai etiketė teisinga, o prieiga vis tiek nepavyksta

Pradėkite nuo tėvinių katalogų. Praėjimo leidimas tikrinamas kiekviename kelio komponente, todėl teisingai pažymėtas sertifikatas kataloge, į kurį paslauga negali patekti, vis tiek lieka neperskaitomas. Ir SELinux, ir įprasta teisė turi leisti kiekvieną žingsnį, o vienos pataisymas nepataiso kitos.

Tada patikrinkite proceso tapatybę ir pačios paslaugos smėlio dėžę. Vienetas su ribojančia smėlio dėže gali uždrausti prieigą prie failo, kurį politika mielai leistų, o iš žurnalo eilutės abi priežastys atrodo vienodai. Patvirtinkite, kuris procesas iš tikrųjų klausia, o ne kuris, jūsų manymu, klausia.

Atminkite, kad dontaudit taisyklės gali slopinti atsisakymo pranešimus, todėl tuščias audito žurnalas yra silpnas įrodymas, o ne įrodymas. Jei politika atrodo teisinga, o prieiga vis tiek nepavyksta, ištirkite prieš generuodami plačią leidimo modulį ir neišjunkite SELinux, kad simptomas išnyktų. Abu trumpi keliai duoda sistemą, kuri atrodo veikianti, ir saugumo poziciją, kurios niekas negali aprašyti. Trumpas tyrimas geresnis už bet kurį iš jų.