Kāpēc VPN sertifikāta pārvietošana salauž tā SELinux etiķeti

Sertifikāti var atrasties pareizajā direktorijā ar lasāmu režīmu un root īpašumtiesībām, un pakalpojums tomēr var ziņot, ka tas nevar atvērt failu. SELinux sistēmā šī kombinācija norāda uz vienu konkrētu mehānismu, nevis uz atļaujām. Etiķete ceļoja kopā ar failu, jo pārdēvēšana neizveido jaunu objektu. Inode saglabāja drošības kontekstu, kas tam bija vecajā ceļā, un jaunā ceļa politika nekad nesaņēma iespēju piešķirt savējo.

Ko pārdēvēšana patiešām dara ar etiķeti

Fails nes savu SELinux kontekstu kā atribūtu datus, kas piesaistīti inode. Pārdēvēšana vienā failu sistēmā maina direktorijas ierakstu un neko citu, kas ir ātri un atomiski, un tas ir iemesls, kāpēc konteksts pārdzīvo pārvietošanu. Nekāda politika netiek vaicāta, nekāda noklusējuma vērtība netiek piemērota un nekāds brīdinājums netiek izdrukāts.

Kopēšana uzvedas citādi. Kopija izveido jaunu inode mērķa direktorijā, un politika piešķir kontekstu pēc šīs direktorijas tipa, tāpēc nokopēts sertifikāts parasti iegūst pareizu etiķeti, bet pārvietotais paliek nepareizs. Tieši šī vienīgā atšķirība izskaidro lielāko daļu apjukuma šajā biļešu klasē.

Pārvietošana starp failu sistēmām atgriežas pie kopēšanas semantikas, tāpēc viena un tā pati komanda divās mašīnās var uzvesties atšķirīgi atkarībā no tā, vai /etc atrodas savā atsevišķā sējumā. Pārbaudiet to pirms secināt, ka rīks ir neuzticams. Viens skatiens uz montāžas tabulu pateiks, kāda veida pārvietošanu jūs veicāt.

Izlasiet pašreizējo etiķeti pret gaidīto

Trīs tikai lasīšanas komandas atbild uz jautājumu, neko nemainot. Pirmā parāda, kas failam tagad ir, otrā ziņo, ko politika gaida tieši šim ceļam, un trešā uzskaita katru failu direktorijā, kura etiķete atšķiras.

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

Uzticēties ir mēģinājuma palaišanai, jo tā nosauc katru failu, kura konteksts atšķiras no politikas, un tomēr atstāj sistēmu neskartu. Ja sertifikāts parādās šajā sarakstā, jūs esat atraduši neatbilstību starp to, ko nozīmē ceļš, un to, ko apgalvo fails. Ja tas neparādās, etiķete jau ir tā, ko vēlas politika, un jūsu laiks pieder citur.

Pēc tam saistiet atšķirību ar faktisku atteikumu. Neatbilstība ir pierādījums par nepareizu etiķeti, nevis pierādījums, ka pakalpojums tāpēc neizdevās, un labojums, kas piemērots bez atbilstoša atteikuma žurnālā, ir minējums ar papildu soļiem.

Atjaunojiet kartējumu, nevis izdomājiet izņēmumu

Standarta vietai politika jau kartē ceļu, tāpēc restorecon piemēro to, un darbs ir pabeigts. Turiet tvērumu direktorijā, kuru labojat; visas failu sistēmas pār marķēšana ir lēna, traucējoša, un tā apglabā sākotnējo kļūdu zem ļoti lielas izmaiņas.

Pielāgotai direktorijai secība ir svarīga, un tās apgriešana rada komandu, kas ziņo par panākumiem, neko nemainot. Kartējums pieder politikai, pār marķēšana pieder beigām, un mēģinājuma palaišana pieder pirms abām. Šīs pēdējās daļas izlaišana ir veids, kā ceļš, kas nekad nav bijis nepareizs, tomēr tiek pār marķēts.

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

restorecon piemēro kartējumu; tas nevar to izdomāt. Ja neviena kārtula neapraksta ceļu, nav ko atjaunot, tāpēc pastāvīgajam kartējumam jāpastāv pirms pār marķēšanas. Pierakstiet, kura konfigurācija pārvalda šo kartējumu, jo citādi vēlāka pārvietošana, pakotnes atjauninājums vai pār marķēšana atkal rada defektu un nākamais cilvēks sāk no nulles.

Kāpēc chcon nav risinājums

chcon ieraksta kontekstu tieši failā. Tas stājas spēkā nekavējoties, un tas ir vismazāk noturīgais pieejamais variants, jo failu sistēmas pār marķēšana atkārtoti piemēro politiku un bez jautāšanas izmet manuālās izmaiņas. Fails izskatās salabots, un labojumam ir derīguma termiņš, ko neviens nav pierakstījis. Tā vietā jums vajadzīga kārtula, kas apraksta ceļu, lai katrs tur ienākošais fails automātiski saņemtu tādu pašu apstrādi.

Vēl ļaunāk, tas māca nepareizu mācību: pamatā esošais kartējums joprojām trūkst, tāpēc defekts atgriežas pēc nedēļām bez acīmredzama ierosinātāja un bez atmiņas par šo apieto risinājumu. Izmantojiet chcon tikai kā pagaidu eksperimentu hipotēzes apstiprināšanai, pēc tam aizstājiet to ar kartējumu, kas pārdzīvo nākamo pār marķēšanu, un pārbaudiet, vai aizstājējs patiešām ir savā vietā.

Kad etiķete ir pareiza un piekļuve tomēr neizdodas

Sāciet ar vecākdirektorijiem. Šķērsošanas atļauja tiek pārbaudīta katrā ceļa komponentā, tāpēc pareizi marķēts sertifikāts direktorijā, kurā pakalpojums nevar iekļūt, joprojām paliek nelasāms. Gan SELinux, gan parastajai atļaujai jāatļauj katrs solis, un vienas labošana nelabo otru.

Pēc tam pārbaudiet procesa identitāti un paša pakalpojuma smilškasti. Vienība ar ierobežojošu smilškasti var liegt piekļuvi failam, ko politika labprāt atļautu, un no žurnāla rindas abi cēloņi izskatās vienādi. Apstipriniet, kurš process patiešām jautā, nevis kurš, jūsuprāt, jautā.

Atcerieties, ka dontaudit kārtulas var nomākt atteikuma ziņojumus, tāpēc tukšs audita žurnāls ir vājš pierādījums, nevis pierādījums. Ja politika izskatās pareiza un piekļuve tomēr neizdodas, izmeklējiet pirms plaša atļaujas moduļa ģenerēšanas un neizslēdziet SELinux, lai simptoms pazustu. Abi īsie ceļi dod sistēmu, kas izskatās strādājam, un drošības pozīciju, ko neviens nevar aprakstīt. Īsa izmeklēšana ir labāka par jebkuru no tiem.