VPN sertifikasını taşımak SELinux etiketini neden bozar

Sertifikalar doğru dizinde okunabilir bir mod ve root sahipliğiyle durabilir ve hizmet yine de dosyayı açamadığını bildirebilir. Bir SELinux sisteminde bu bileşim izinlere değil, belirli bir mekanizmaya işaret eder. Etiket dosyayla birlikte taşındı, çünkü yeniden adlandırma yeni bir nesne oluşturmaz. inode, eski yolda sahip olduğu güvenlik bağlamını korudu ve yeni yolun politikası kendi bağlamını atama fırsatını hiç bulamadı.

Yeniden adlandırma bir etikete gerçekte ne yapar

Bir dosya SELinux bağlamını inode'a bağlı öznitelik verisi olarak taşır. Tek bir dosya sistemi içinde yeniden adlandırma dizin girdisini değiştirir ve başka hiçbir şeyi değiştirmez; bu hızlı ve atomiktir ve bağlamın taşımadan sağ çıkmasının nedeni de budur. Hiçbir politika sorgulanmaz, hiçbir varsayılan uygulanmaz ve hiçbir uyarı yazdırılmaz.

Kopyalama farklı davranır. Bir kopya hedef dizinde yeni bir inode oluşturur ve politika bağlamı o dizinin türüne göre atar, bu yüzden kopyalanan sertifika genellikle doğru etiketle biterken taşınan yanlış kalır. Tam da bu tek fark, bu tür biletlerdeki karışıklığın çoğunu açıklar.

Dosya sistemleri arasındaki taşımalar kopyalama anlambilimine geri döner, bu yüzden aynı komut iki makinede /etc kendi biriminde mi duruyor sorusuna göre farklı davranabilir. Aracın güvenilmez olduğu sonucuna varmadan önce bunu kontrol edin. Bağlama tablosuna bir bakış, ne tür bir taşıma yaptığınızı söyler.

Geçerli etiketi beklenen etiketle karşılaştırarak okuyun

Üç salt okunur komut, hiçbir şeyi değiştirmeden soruyu yanıtlar. Birincisi dosyanın şu anda neye sahip olduğunu gösterir, ikincisi politikanın tam o yol için ne beklediğini bildirir, üçüncüsü ise dizin altında etiketi farklı olan her dosyayı listeler.

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

Güvenilmesi gereken kuru çalıştırmadır, çünkü bağlamı politikadan sapan her dosyayı adlandırır ve sistemi yine de dokunulmamış bırakır. Sertifika o listede görünüyorsa, yolun ne anlama geldiği ile dosyanın ne iddia ettiği arasındaki tutarsızlığı bulmuşsunuzdur. Görünmüyorsa etiket zaten politikanın istediği şeydir ve zamanınız başka bir yere aittir.

Ardından farkı gerçek bir ret ile ilişkilendirin. Uyuşmazlık yanlış etiketin kanıtıdır, hizmetin bu yüzden başarısız olduğunun kanıtı değildir ve günlükte karşılık gelen bir ret olmadan uygulanan düzeltme, fazladan adımları olan bir tahmindir.

Bir istisna uydurmak yerine eşlemeyi geri yükleyin

Standart bir konum için politika yolu zaten eşler, bu yüzden restorecon onu uygular ve iş biter. Kapsamı onardığınız dizinde tutun; tüm dosya sistemini yeniden etiketlemek yavaştır, rahatsız edicidir ve asıl hatayı çok büyük bir değişikliğin altına gömer.

Özel bir dizin için sıra önemlidir ve bunu tersine çevirmek hiçbir şeyi değiştirmeden başarı bildiren bir komut üretir. Eşleme politikaya aittir, yeniden etiketleme sona aittir ve kuru çalıştırma ikisinden önceye aittir. O son kısmı atlamak, hiç yanlış olmamış bir yolun yine de yeniden etiketlenmesinin yoludur.

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

restorecon bir eşleme uygular; bir tane uyduramaz. Hiçbir kural yolu tanımlamıyorsa geri yüklenecek bir şey yoktur, bu yüzden kalıcı eşlemenin yeniden etiketlemeden önce var olması gerekir. Hangi yapılandırmanın o eşlemeye sahip olduğunu not edin, çünkü aksi halde sonraki bir taşıma, paket güncellemesi veya yeniden etiketleme hatayı yeniden yaratır ve sıradaki kişi sıfırdan başlar.

chcon neden çözüm değil

chcon bağlamı doğrudan dosyaya yazar. Hemen etki eder ve mevcut en az kalıcı seçenektir, çünkü dosya sisteminin yeniden etiketlenmesi politikayı yeniden uygular ve elle yapılan değişiklikleri sormadan atar. Dosya onarılmış görünür ve onarımın kimsenin yazmadığı bir son kullanma tarihi vardır. Bunun yerine istediğiniz, yolu tanımlayan bir kuraldır; böylece oraya gelen her dosya otomatik olarak aynı muameleyi görür.

Daha kötüsü, yanlış dersi öğretir: alttaki eşleme hâlâ eksiktir, bu yüzden hata haftalar sonra belirgin bir tetikleyici ve o geçici çözümün hatırası olmadan geri döner. chcon'yı yalnızca bir hipotezi doğrulamak için geçici bir deney olarak kullanın, sonra onu bir sonraki yeniden etiketlemeyi atlatan bir eşlemeyle değiştirin ve değiştirmenin gerçekten yerinde olduğunu kontrol edin.

Etiket doğruyken erişim hâlâ başarısız olduğunda

Üst dizinlerle başlayın. Geçiş izni yolun her bileşeninde denetlenir, bu yüzden hizmetin giremediği bir dizin içindeki doğru etiketlenmiş sertifika yine de okunamaz. Hem SELinux hem de olağan izin her adıma izin vermelidir ve birini düzeltmek diğerini düzeltmez.

Ardından süreç kimliğini ve hizmetin kendi sanal alanını denetleyin. Kısıtlayıcı bir sanal alana sahip bir birim, politikanın memnuniyetle izin vereceği bir dosyaya erişimi reddedebilir ve günlük satırından iki neden aynı görünür. Gerçekte hangi sürecin sorduğunu doğrulayın, sorduğunu varsaydığınızı değil.

dontaudit kurallarının ret mesajlarını bastırabileceğini unutmayın, bu yüzden boş bir denetim günlüğü kanıt değil, zayıf bir delildir. Politika doğru görünüyorsa ve erişim hâlâ başarısızsa, geniş bir izin modülü üretmeden önce araştırın ve belirti kaybolsun diye SELinux'u devre dışı bırakmayın. Her iki kısa yol da çalışıyor gibi görünen bir sistem ve kimsenin tanımlayamadığı bir güvenlik duruşu üretir. Kısa bir araştırma ikisinden de iyidir.