AppArmor Unix Socket Arabuluculuğu İstemci ve Sunucu Tarafında Kurallar Gerektirir

Bir Unix domain socket iletişiminin yalnızca bir ucuna izin veren bir AppArmor profili eksik bir politikadır. Dev.to'da yayımlanan bir yazının ana noktası budur; yazı, AppArmor'un yerel socket trafiğini nasıl yönettiğini, istemci ve sunucu taraflarının neden kurallara ihtiyaç duyduğunu ve politikanın gerçekte isteneni zorunlu kıldığını nasıl doğrulayacağınızı ele alıyor.

AppArmor neyi denetler

Unix domain socketler yerel servisler arasındaki standart bir kontrol kanalıdır. Yazıya göre bunlar sıklıkla ağ denetiminden kaçar, dosya sistemi izinlerine dayanır veya diskte dosya olarak hiç görünmeyen abstract isimler kullanır. Alıntılanan apparmor.d(5) dokümantasyonu, dosya sistemi tabanlı, abstract ve anonim Unix socketler için arabuluculuğu tanımlıyor. Kurallar socket adresini, peer'ın etiketini ve işlemi ayırt edebilir; ayrıca ince taneli arabuluculuk destekleyen sistemlerde eski kaba ağ kuralı, eşdeğer socket kuralına dönüştürülür.

Her iki uç nokta kurallara ihtiyaç duyar

Tuzak bu asimetride. Bir istemci profili connect işlemi için yeterince dar kapsamlı olabilirken, dinleyen servis aynı anda herhangi bir peer'dan bağlantı kabul edebilir. Bu yapılandırmada, ele geçirilmiş bir istemci, politikanın hiç açığa çıkarmak istemediği daha ayrıcalıklı bir servise erişebilir. Yazı, hem dinleme (listen) yolunu hem de connect yolunun korunmasını ve yardımcı süreçler ile kısa ömürlü alt süreçlerin aynı etiketi devraldığı, dolayısıyla ebeveyndekiyle aynı kurallara tabi olduklarının hatırlanmasını öneriyor.

Adresler ve etiketler ayrı sinyallerdir

Bir dosya sistemi socketinin bir yolu vardır; bir abstract socket ise abstract isim alanında bir adrese sahiptir ve kalıcı bir dizin girdisi yoktur. Yazıya göre yalnızca adresi eşleştirmek peer'ın güvenilir olduğunu kanıtlamaz, çünkü peer'ın AppArmor etiketi bağımsız bir denetimdir ve platform destekliyorsa her ikisi birlikte değerlendirilmelidir. Pattern eşleştirme ayrıca yazarları şaşırtabilecek şekillerde dosya yolu kurallarını izler: tek bir dizin düzeyini kapsadığı görünen bir wildcard, adres içindeki bir slash ile eşleşmeyebilir ve abstract isimler kendi gösterimini kullanır. Makale, bir dosya sistemi yolu patternini abstract socket kuralına kopyalayıp anlamının aynı kalacağını varsaymama konusunda uyarıyor.

Fail-closed davranış bir hata gibi görünebilir

Dokümantasyon, bellek tahsisinin başarısız olması durumunda arabuluculuğun fail-closed davranabileceğini belirtiyor. Yazıya göre bu doğru bir varsayılan davranıştır, ancak belirsiz operasyonel belirtiler üretir: bir servis, kaynak kullanımının tavan yaptığı sırada ENOMEM veya reddedilmiş bir bağlantı görebilir. Loglar, mesaj içeriklerini veya kimlik bilgilerini dökmeden profili ve işlemi reddeden spesifik kuralı tanımlamalıdır.

Test farklı peer etiketleri gerektirir

Yaygın bir test hatası, socketi root olarak oluşturup aynı kullanıcıyla bağlanmaktır. Her iki süreç tek bir profili paylaştığında bu hiçbir şey kanıtlamaz, çünkü hedeflenen peer-label kuralı hiç tetiklenmez. Önerilen prosedür, istemciyi kendi profili altında çalıştırmak, bağlantıyı denemek ve audit sonucunu kaydetmek, ardından sunucunun accept yolunu ve istemcinin connect yolunu bağımsız olarak incelemektir. Yazı ayrıca bir profilin başarıyla yüklenmiş olmasının, istenen kuralı zorunlu kıldığının kanıtı olmadığını vurguluyor; operatörler yüklenen profili, kernel özellik setini ve audit kaydını kontrol etmeli, test sonucunu servis sürümü ve host imajıyla birlikte kaydetmelidir.

Bir gözden geçirme kontrol listesi

Yazı, yerel kontrol kanallarının envanteriyle başlamayı öneriyor: socket yolu veya abstract adı, dinleyici süreç ve profili, beklenen istemci süreçleri ve etiketleri, her istemcinin ihtiyaç duyduğu işlemler, socket üzerinden taşınan kimlik bilgileri ve ilgili dosya sistemi izinleri ile mount görünümleri. Daha sonra, herhangi bir peer'ın ayrıcalıklı bir işleme erişmesine izin veren geniş kurallar kaldırılmalıdır. Bir servisin birden çok istemcisi olduğunda, ayrıcalıklı uç nokta ile yönetim uç noktası ayrılmalı ya da uygulama seviyesinde bir yetkilendirme denetimi eklenmelidir, çünkü AppArmor peer'ı kısıtlayabilir ama sunucu yine de isteği doğrulamak zorundadır.

Profilin bittiği yer

Unix socket arabuluculuğu, veri güvenilir bir süreç tarafından alındıktan sonra onu korumaz. İzinli bir istemci yine de kötü niyetli bir payload gönderebilir ve izinli bir sunucu kendi iş mantığı aracılığıyla dosyaları açığa çıkarabilir. Profil ayrıca dosya sistemi izinlerinin, servis kimlik doğrulamasının veya en az ayrıcalıklı süreç kimliklerinin yerini almaz.

Neden önemli

Yerel socketler çoğu zaman bir servisin yönetim düzlemi ile host üzerindeki diğer her şey arasında durur ve tipik olarak kuruluşların başka yerlerde güvendiği ağ denetimlerini atlatır. Bu iletişimi açık hale getirmek — belirli bir etiketin belirli bir adrese bağlanmasına ve sunucunun yalnızca o etiketten kabul etmesine izin vermek — örtük yerel güveni denetlenebilir ve regresyon testine tabi tutulabilir bir politikaya dönüştürür. Her iki uç nokta kuralı, kısıtlayıcı görünen bir profil ile ele geçirilmiş bir istemciyi gerçekten izole eden profili birbirinden ayıran şeydir.