Terminalde root, SELinux altında reddedildi: hook neden başarısız oluyor

up betiğini root olarak çalıştırırsınız, tamamlanır ve servis onu çağırdığında aynı betik başarısız olur. Dosya izinlerinde hiçbir şey değişmedi, bu yüzden doğal sonraki adım onları yeniden gevşetmektir, ki bu hiçbir şeyi düzeltmez. Bir SELinux ana bilgisayarında belirleyici etken çoğu zaman sürecin kim olduğu değil, hangi alanda çalıştığıdır ve sınırlı bir alanın içindeki root yine sınırlı kalır.

Aynı komut, iki farklı güvenlik alanı

Tür zorlaması kaynak alanı, hedef etiketi ve istenen işlemi birlikte değerlendirir. Terminal oturumunuz sınırsız veya yönetici bir alanda çalışır, arka plan programı ise birimine atanmış alanda çalışır. Bu yüzden aynı komutlar farklı kararlar üretir ve bu fark politika hatası değil, kasıtlıdır.

Bu nedenle iki çalıştırmayı karşılaştırmak yalnızca bağlamlarını karşılaştırırsanız yararlıdır. Aynı komutu kabuktan ve hook'tan çalıştırın; kabuk sürümü ikili dosyanın var olduğunu ve argümanların doğru olduğunu kanıtlar, ancak servisin onu çalıştırma izni olup olmadığı hakkında hiçbir şey kanıtlamaz. İki yolla da çalıştırın ve yalnızca çıkış kodlarını değil, alanları karşılaştırın. Belirsiz bir izin şikayetini tek bir alan ve tek bir etiket hakkında somut bir soruya dönüştüren tam olarak bu karşılaştırmadır.

Bu arızanın klasik biçimi, harici bir aracı çağıran bir yardımcıdır. Hook'un kendisi izinli olabilir, ancak çağırdığı araç servis alanının çalıştıramayacağı bir etiket taşır veya etiketi bunu yasaklayan dizine yazar.

AVC kaydını hook hatasının yanında okuyun

AVC reddi davayı belirleyen alanları adlandırır: sürecin kaynak bağlamı, nesnenin hedef bağlamı, nesne sınıfı ve reddedilen belirli izin. Bir teori kurmadan önce dördünü de okuyun, çünkü yürütmeye ilişkin ret ile yazmaya ilişkin ret tamamen farklı onarımlar gerektirir.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

Kaynak bağlamı servisin gerçekte çalıştığı alana, hedef bağlamı ise işlemin dokunduğu dosya veya dizinin etiketine karşılık gelmelidir. İkisinden biri izlediğiniz hatayla uyuşmuyorsa başka bir olayı okuyorsunuz.

Kaydın yanına politika sürümünü ve çalıştırılabilir dosyanın tam yolunu not edin. Bir dağıtımın politikasında görünen alan adı o kurulum hakkında kanıttır, başka bir derlemenin aynı kuralları sağladığının garantisi değildir. Bu bağlam, başka birinin sizin sonucunuzu kendi ana bilgisayarında yinelemesini sağlayan şeydir. O olmadan kayıt kanıt gibi değil anekdot gibi okunur.

Etiket, yapılandırma veya politika: üç onarım

İlk onarım, dosyanın kurulu konumuyla uyuşmayan bir etikettir. cp ile yerine kopyalanan veya bir düzenleyiciyle yazılan bir betik, servis alanının kullanamayacağı varsayılan bir etiket taşıyabilir ve beklenen bağlamı geri yüklemek politikaya hiç dokunmadan bunu düzeltir.

İkincisi yapılandırmadır. Dağıtım, işlemi çalıştırmanın desteklenen bir yolunu, yardımcı için belgelenmiş bir dizini veya bunu zaten izin veren güncellenmiş bir politika paketini sunabilir. Düzeninizi desteklenene değiştirmek politika yazmaktan daha ucuzdur ve güncellemeleri atlatır.

Üçüncüsü gerçekten eksik olan bir kuraldır ve son çare olmalıdır. Denetim araçlarıyla bir aday üretin, gerçekte neye izin verdiğini okuyun, gözlemlediğiniz işleme ve alana daraltın ve üretime yaklaşmadan önce başka birine inceletin.

Eski bir allow modülü neden yanıt değil

Bu arıza için arama sonuçları hazır modüllerle doludur, çoğu zaman hook'un artık çağırmadığı bir araç için. Birini kurmak reddinizle hiç ilgisi olmayabilecek izinler verir ve kalıcı bir delik eklerken gerçek uyumsuzluğu yerinde bırakır.

Bir sonraki hatayı da gizler. Geniş bir işlem sınıfına izin veren bir modül bu hatayı ortadan kaldırır ve bir sonrakini ilişkilendirilmesi çok daha zor bir şeye dönüştürür. Modülü sonradan kaldırmak da kimsenin planlamak istemediği bir değişikliktir, bu yüzden kısa yol kalıcı olma eğilimindedir.

Disiplinli karşılaştırma, okuyabildiğiniz ret ile önerdiğiniz değişiklik arasındadır. Red Hat'in SELinux sorun giderme kılavuzu etiket ve yapılandırma denetimlerini tam da bu nedenle üretilmiş politikanın önüne koyar. Kayıtta karşılık gelen bir ret yoksa SELinux muhtemelen sizin sorununuz değildir ve yol, sandbox veya izin sorunları hâlâ açıktır.