VPN sertifikatının köçürülməsi SELinux etiketini niyə pozur

Sertifikatlar düzgün qovluqda oxuna bilən rejim və root sahibliyi ilə yerləşə bilər, və xidmət yenə də faylı aça bilmədiyini bildirə bilər. SELinux sistemində bu birləşmə icazələrə deyil, konkret bir mexanizmə işarə edir. Etiket fayl ilə birlikdə getdi, çünki ad dəyişmə yeni obyekt yaratmır. İnod köhnə yolda malik olduğu təhlükəsizlik kontekstini saxladı və yeni yolun siyasəti heç vaxt öz kontekstini təyin etmək imkanı əldə etmədi.

Ad dəyişmə etiketə əslində nə edir

Fayl öz SELinux kontekstini inoda bağlı atribut məlumatı kimi daşıyır. Bir fayl sistemi daxilində ad dəyişmə yalnız qovluq qeydini dəyişir, başqa heç nəyi, bu sürətli və atomikdir və kontekstin köçmədən sağ qalmasının səbəbidir. Heç bir siyasətə müraciət edilmir, heç bir standart tətbiq olunmur və heç bir xəbərdarlıq çap edilmir.

Kopyalama fərqli davranır. Kopya hədəf qovluqda yeni inod yaradır və siyasət həmin qovluğun tipinə görə kontekst təyin edir, buna görə kopyalanmış sertifikat adətən düzgün etiketlənir, köçürülmüş isə səhv qalır. Bu tək fərq bu tip biletlərdəki qarışıqlığın çoxunu izah edir.

Fayl sistemləri arası köçürmələr kopyalama semantikasına qayıdır, buna görə eyni əmr iki maşında fərqli davrana bilər — /etc öz həcmində yerləşib-yerləşməməsindən asılı olaraq. Alətin etibarsız olduğu qənaətinə gəlməzdən əvvəl bunu yoxlayın. Montaj cədvəlinə bir baxış hansı növ köçürmə etdiyinizi deyir.

Cari etiketi gözlənilənlə müqayisə edin

Üç yalnız oxuma əmri heç nəyi dəyişmədən suala cavab verir. Birincisi faylın hazırda nə olduğunu göstərir, ikincisi siyasətin məhz həmin yol üçün nə gözlədiyini bildirir, üçüncüsü isə qovluq altında etiketi fərqlənən hər faylı sadalayır.

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

Etibarlı olan quru işə salmadır, çünki o, konteksti siyasətdən uzaqlaşan hər faylı adlandırır və sistemi toxunulmaz qoyur. Sertifikat həmin siyahıda görünürsə, yolun mənası ilə faylın iddiası arasındakı uyğunsuzluğu tapmısınız. Görünmürsə, etiket artıq siyasətin istədiyi kimidir və vaxtınız başqa yerə aiddir.

Sonra fərqi faktiki imtinayla əlaqələndirin. Uyğunsuzluq səhv etiketin sübutudur, xidmətin buna görə uğursuz olduğunun sübutu deyil, və jurnalda uyğun imtina olmadan tətbiq edilən düzəliş əlavə addımlarla edilən təxmindir.

İstisna uydurmaq əvəzinə xəritələməni bərpa edin

Standart yer üçün siyasət yolu artıq xəritələyib, ona görə restorecon onu tətbiq edir və iş bitir. Əhatəni təmir etdiyiniz qovluqla məhdudlaşdırın; bütün fayl sistemini yenidən etiketləmək yavaş, dağıdıcıdır və ilkin səhvi çox böyük dəyişiklik altında basdırır.

Fərdi qovluq üçün sıra vacibdir və onu tərsinə çevirmək heç nəyi dəyişmədən uğur bildirən əmr yaradır. Xəritələmə siyasətə, yenidən etiketləmə sona, quru işə salma isə hər ikisindən əvvələ aiddir. Son hissəni atlamaq heç vaxt səhv olmayan yolun yenə də etiketlənməsinin yoludur.

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

restorecon xəritələmə tətbiq edir; yenisini yarada bilməz. Heç bir qayda yolu təsvir etmirsə, bərpa üçün heç nə yoxdur, buna görə davamlı xəritələmə yenidən etiketləmədən əvvəl mövcud olmalıdır. Hansı konfiqurasiyanın o xəritələməyə sahib olduğunu qeyd edin, çünki sonrakı köçürmə, paket yeniləməsi və ya yenidən etiketləmə əks halda nasazlığı yenidən yaradır və növbəti şəxs sıfırdan başlayır.

Niyə chcon həll deyil

chcon konteksti birbaşa faylın üzərinə yazır. Dərhal qüvvəyə minir və mövcud ən az davamlı seçimdir, çünki fayl sistemi yenidən etiketləməsi siyasəti yenidən tətbiq edir və əl dəyişikliklərini soruşmadan atır. Fayl təmir edilmiş görünür və təmirin heç kimin yazmadığı bitmə tarixi var. Əvəzində istədiyiniz yolu təsvir edən qaydadır ki, ora gələn hər fayl eyni rəftarı avtomatik alsın.

Daha pisi, yanlış dərsi öyrədir: əsas xəritələmə hələ də yoxdur, buna görə nasazlıq həftələr sonra aydın tetikləyici və hiyləyə dair yaddaş olmadan qayıdır. chcon yalnız fərziyyəni təsdiqləmək üçün müvəqqəti eksperiment kimi istifadə edin, sonra onu növbəti yenidən etiketləmədən sağ çıxan xəritələmə ilə əvəz edin və əvəzləmənin həqiqətən yerində olduğunu yoxlayın.

Etiket düzgün olduqda və giriş yenə də alınmadıqda

Ana qovluqlardan başlayın. Keçid icazəsi yolun hər komponentində yoxlanılır, buna görə xidmətin girə bilmədiyi qovluqdakı düzgün etiketlənmiş sertifikat yenə də oxunmaz qalır. Həm SELinux, həm də adi icazə hər addıma icazə verməlidir və birini düzəltmək digərini düzəltmir.

Sonra proses kimliyini və xidmətin öz sandbox-unu yoxlayın. Məhdudlaşdırıcı sandbox-u olan vahid siyasətin məmnuniyyətlə icazə verəcəyi fayla girişi inkar edə bilər və jurnal sətrindən iki səbəb eyni görünür. Həqiqətən hansı prosesin soruşduğunu təsdiqləyin, soruşduğunu güman etdiyinizi deyil.

Unutmayın ki, dontaudit qaydaları imtina mesajlarını susdura bilər, buna görə boş audit jurnalı sübut deyil, zəif dəlildir. Siyasət düzgün görünürsə və giriş yenə alınmırsa, geniş icazə modulu yaratmazdan əvvəl araşdırın və simptomu yox etmək üçün SELinux-u söndürməyin. Hər iki qısa yol işləyən kimi görünən sistem və heç kimin təsvir edə bilmədiyi təhlükəsizlik mövqeyi yaradır. Qısa araşdırma ikisindən də yaxşıdır.