Zašto premještanje VPN certifikata kvari njegovu SELinux oznaku

Certifikati mogu stajati u ispravnom direktoriju s čitljivim načinom rada i vlasništvom roota, a usluga ipak može prijaviti da ne može otvoriti datoteku. Na SELinux sustavu ta kombinacija upućuje na jedan određeni mehanizam, a ne na dopuštenja. Oznaka je putovala s datotekom jer preimenovanje ne stvara novi objekt. Inode je zadržao sigurnosni kontekst koji je imao na staroj stazi, a politika za novu stazu nikad nije dobila priliku dodijeliti vlastiti.

Što preimenovanje zapravo čini oznaci

Datoteka nosi svoj SELinux kontekst kao podatke atributa pridružene inodeu. Preimenovanje unutar jednog datotečnog sustava mijenja unos u direktoriju i ništa drugo, što je brzo i atomski, i razlog je zašto kontekst preživljava premještanje. Nikakva politika se ne pita, nikakva zadana vrijednost se ne primjenjuje i nikakvo upozorenje se ne ispisuje.

Kopiranje se ponaša drukčije. Kopija stvara novi inode u odredišnom direktoriju, a politika dodjeljuje kontekst prema tipu tog direktorija, pa kopirani certifikat obično završi s ispravnom oznakom, dok premješteni ostaje pogrešan. Ta jedna razlika objašnjava većinu zabune u ovoj vrsti tiketa.

Premještanja između datotečnih sustava vraćaju se semantici kopiranja, pa se ista naredba može ponašati različito na dva računala, ovisno o tome živi li /etc na vlastitom volumenu. Provjerite to prije nego zaključite da je alat nepouzdan. Jedan pogled na tablicu montiranja kaže vam koju ste vrstu premještanja izvršili.

Pročitajte trenutačnu oznaku nasuprot očekivanoj

Tri naredbe samo za čitanje odgovaraju na pitanje bez promjene ičega. Prva pokazuje što datoteka sada ima, druga izvješćuje što politika očekuje za tu točnu stazu, a treća navodi svaku datoteku ispod direktorija čija se oznaka razlikuje.

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

Probni prolaz je onaj kojemu treba vjerovati, jer imenuje svaku datoteku čiji kontekst odstupa od politike, a sustav i dalje ostavlja netaknutim. Ako se certifikat pojavi na tom popisu, pronašli ste razliku između onoga što staza znači i onoga što datoteka tvrdi. Ako se ne pojavi, oznaka je već ono što politika želi i vaše vrijeme pripada negdje drugdje.

Zatim povežite razliku sa stvarnim odbijanjem. Nepodudarnost je dokaz pogrešne oznake, a ne dokaz da je usluga zbog toga zakazala, a popravak primijenjen bez odgovarajućeg odbijanja u zapisu je nagađanje s dodatnim koracima.

Vratite mapiranje umjesto da izmišljate iznimku

Za standardnu lokaciju politika već mapira stazu, pa restorecon primjenjuje to i posao je gotov. Držite obuhvat na direktoriju koji popravljate; ponovno označavanje cijelog datotečnog sustava je sporo, ometajuće i sahranjuje izvornu pogrešku pod vrlo velikom promjenom.

Za prilagođeni direktorij redoslijed je važan, a njegovo obrtanje daje naredbu koja izvješćuje uspjeh dok ništa ne mijenja. Mapiranje pripada politici, ponovno označavanje pripada kraju, a probni prolaz pripada prije obojega. Preskakanje tog posljednjeg dijela način je na koji staza koja nikad nije bila pogrešna ipak bude ponovno označena.

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

restorecon primjenjuje mapiranje; ne može ga izmisliti. Ako nijedno pravilo ne opisuje stazu, nema odakle vratiti, zato trajno mapiranje mora postojati prije ponovnog označavanja. Zapišite koja konfiguracija posjeduje to mapiranje, jer kasnije premještanje, ažuriranje paketa ili ponovno označavanje inače ponovno stvara kvar i sljedeća osoba počinje od nule.

Zašto chcon nije rješenje

chcon upisuje kontekst izravno na datoteku. Djeluje odmah i to je najmanje trajna dostupna opcija, jer ponovno označavanje datotečnog sustava ponovno primjenjuje politiku i odbacuje ručne promjene bez pitanja. Datoteka izgleda popravljena, a popravak ima datum isteka koji nitko nije zapisao. Ono što umjesto toga želite jest pravilo koje opisuje stazu, tako da svaka datoteka koja tamo stigne automatski dobije isti tretman.

Gore od toga, to uči pogrešnu lekciju: temeljno mapiranje još uvijek nedostaje, pa se kvar vraća tjednima kasnije bez očitog okidača i bez sjećanja na zaobilazno rješenje. Rabite chcon samo kao privremeni eksperiment za potvrdu hipoteze, zatim ga zamijenite mapiranjem koje preživljava sljedeće ponovno označavanje i provjerite je li zamjena stvarno na mjestu.

Kad je oznaka ispravna, a pristup ipak ne uspijeva

Počnite s nadređenim direktorijima. Dopuštenje za prolaz provjerava se na svakoj komponenti staze, pa ispravno označen certifikat u direktoriju u koji usluga ne može ući ostaje nečitljiv. I SELinux i obično dopuštenje moraju dopustiti svaki korak, a popravak jednoga ne popravlja drugo.

Zatim provjerite identitet procesa i vlastiti sandbox usluge. Jedinica s restriktivnim sandboxom može odbiti pristup datoteci koju bi politika rado dopustila, a iz retka zapisa dva uzroka izgledaju jednako. Potvrdite koji proces zapravo traži, a ne koji pretpostavljate da traži.

Imajte na umu da pravila dontaudit mogu potisnuti poruke o odbijanju, pa je prazan revizijski zapis slab dokaz, a ne dokaz. Ako politika izgleda ispravno, a pristup ipak ne uspijeva, istražite prije generiranja širokog modula dopuštenja i ne isključujte SELinux da bi simptom nestao. Oba kratka puta daju sustav koji izgleda da radi i sigurnosni stav koji nitko ne može opisati. Kratko istraživanje bolje je od bilo kojega od njih.