Zašto premeštanje VPN sertifikata 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 sistemu ta kombinacija upućuje na jedan određeni 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 stazi, a politika za novu stazu nikad nije dobila priliku dodeliti vlastiti.

Što preimenovanje zapravo čini oznaci

Datoteka nosi svoj SELinux kontekst kao podatke atributa pridružene inodeu. 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 premeštanje. Nikakva politika se ne pita, nikakva zadana vrijednost se ne primenjuje i nikakvo upozorenje se ne ispisuje.

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

Premeštanja između datotečnih sistema vraćaju se semantici 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 ste vrstu premještanja izvršili.

Pročitajte trenutnu oznaku nasuprot očekivanoj

Tri naredbe samo za čitanje odgovaraju na pitanje bez promjene ičega. Prva pokazuje što datoteka sada ima, druga izveštava š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 sistem 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 vreme pripada negdje drugdje.

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

Vratite mapiranje umesto da izmišljate iznimku

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

Za prilagođeni direktorij redoslijed je važan, a njegovo obrtanje daje naredbu koja izveštava uspjeh dok ništa ne mijenja. Mapiranje pripada politici, ponovno označavanje pripada kraju, a probni prolaz pripada prije obojega. Preskakanje tog poslednjeg 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 primenjuje 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 premeštanje, ažuriranje paketa ili ponovno označavanje inače ponovno stvara kvar i sledeća osoba počinje od nule.

Zašto chcon nije rešenje

chcon upisuje kontekst izravno na datoteku. Djeluje odmah i to je najmanje trajna dostupna opcija, jer ponovno označavanje datotečnog sistema ponovno primenjuje politiku i odbacuje ručne promjene bez pitanja. Datoteka izgleda popravljena, a popravak ima datum isteka koji nitko nije zapisao. Ono što umesto 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š uvek nedostaje, pa se kvar vraća nedeljama kasnije bez očitog okidača i bez sećanja na zaobilazno rešenje. Koristite chcon samo kao privremeni eksperiment za potvrdu hipoteze, zatim ga zamijenite mapiranjem koje preživljava sledeće ponovno označavanje i proverite je li zamjena stvarno na mestu.

Kad je oznaka ispravna, a pristup ipak ne uspijeva

Počnite s nadređenim direktorijima. Dopuštenje za prolaz proverava 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 dozvola moraju dopustiti svaki korak, a popravak jednoga ne popravlja drugo.

Zatim proverite 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 dozvole i ne isključujte SELinux da bi simptom nestao. Oba kratka puta daju sistem koji izgleda da radi i sigurnosni stav koji nitko ne može opisati. Kratko istraživanje bolje je od bilo kojega od njih.