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 javiti da ne može otvoriti datoteku. Na SELinux sistemu ta kombinacija upućuje na jedan konkretan mehanizam, a ne na dozvole. Oznaka je putovala s datotekom, jer preimenovanje ne stvara novi objekt. Inode je zadržao sigurnosni kontekst koji je imao na staroj putanji, a politika za novu putanju nikada nije dobila priliku dodijeliti svoj.

Šta preimenovanje zapravo radi s oznakom

Datoteka nosi svoj SELinux kontekst kao podatke atributa vezane za inode. Preimenovanje unutar jednog datotečnog sistema 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 drugač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 sistema vraćaju se na semantiku kopiranja, pa se ista naredba može ponašati različito na dva računara, 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 vrstu premještanja ste izvršili.

Pročitajte trenutnu oznaku nasuprot očekivanoj

Tri naredbe samo za čitanje odgovaraju na pitanje bez promjene ičega. Prva pokazuje šta datoteka sada ima, druga izvještava šta politika očekuje za tu točnu putanju, 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 kojem treba vjerovati, jer imenuje svaku datoteku čiji kontekst odstupa od politike, a sistem i dalje ostavlja netaknutim. Ako se certifikat pojavi na tom popisu, pronašli ste razliku između onoga što putanja 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 popravka primijenjena bez odgovarajućeg odbijanja u zapisu je nagađanje s dodatnim koracima.

Vratite mapiranje umjesto da izmišljate izuzetak

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

Za prilagođeni direktorij redoslijed je važan, a njegovo obrtanje daje naredbu koja izvještava 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 putanja koja nikada 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 putanju, 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 sistema ponovno primjenjuje politiku i odbacuje ručne promjene bez pitanja. Datoteka izgleda popravljena, a popravka ima datum isteka koji nitko nije zapisao. Ono što umjesto toga želite je pravilo koje opisuje putanju, tako da svaka datoteka koja tamo stigne automatski dobije isti tretman.

Gore, 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. Koristite 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.

Kada je oznaka ispravna, a pristup ipak ne uspijeva

Počnite s nadređenim direktorijima. Dozvola za prolaz provjerava se na svakoj komponenti putanje, pa ispravno označen certifikat u direktoriju u koji usluga ne može ući ostaje nečitljiv. I SELinux i obična dozvola moraju dopustiti svaki korak, a popravak jednog 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 identično. 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 sistem koji izgleda da radi i sigurnosni položaj koji nitko ne može opisati. Kratko istraživanje bolje je od bilo kojeg od njih.