SELinux Politikası Yazma

Android Açık Kaynak Projesi (AOSP), tüm Android cihazlarda ortak olan uygulamalar ve hizmetler. AOSP'ye katkıda bulunanlar bu politikayı düzenli olarak hassaslaştırmaktadır. Temel politika, cihaza özel politikalarla cihaz üzerindeki son politikanın yaklaşık% 90-95'ini oluşturuyor. özelleştirmelerin %5-10'unu oluşturuyor. Bu makale, cihaza özel bu özelleştirmeler, cihaza özel politikanın nasıl yazılacağı ve bazı tehlikeleri ele aldık.

Cihaz görüntüleme

Cihaza özel politika yazarken aşağıdaki adımları uygulayın.

Daha serbest modda çalıştır

Cihaz izinli modu kullanıyorsanız retler günlüğe kaydedilir ancak zorunlu kılınmaz. İzin modu, iki kullanıcı için önemlidir nedenler:

• İzin modu, politika getirmenin diğer erken aşamaları geciktirmemesini sağlar. bir araç getirme görevi.
• Zorunlu reddetme, diğer retleri de gizleyebilir. Örneğin, dosya erişimi genellikle bir dizin araması, dosya açma ve ardından dosya okumayı gerektirir. İçinde yalnızca dizin araması reddi gerçekleşir. Serbest tüm retlerin görülmesini sağlar.

Bir cihazı serbest moda almanın en basit yolu çekirdek komutu satır ile gösterilir. Bu dosya, cihazın BoardConfig.mk dosyasına eklenebilir: platform/device/<vendor>/<target>/BoardConfig.mk. Komut satırını değiştirdikten sonra make clean işlemini gerçekleştirin ve ardından make bootimage ve yeni başlatma görüntüsünü yükleyin.

Ardından izin modunu şu şekilde onaylayın:

adb shell getenforce

Genel müsabaka modunda olmak için iki haftalık makul bir süre vardır. Reddedilmelerin büyük bir kısmını giderdikten sonra zorunlu kılma moduna geri dönün ve bu hataları çözmek için çok çalışmam gerekecek. Hâlâ ret veya hizmet oluşturmaya devam eden alan adları yoğun geliştirme altında geçici olarak serbest moda alınabilir ancak en kısa sürede tekrar zorunlu kılma moduna geri döndürür.

Erken uygula

Zorunlu modda, retler hem günlüğe kaydedilir hem de zorunlu kılınır. Bu en iyi en kısa sürede cihazınızı zorunlu kılma moduna geçirmek için alıştırma yapın. Bekleniyor Ancak cihaza özgü politikalar oluşturmak ve uygulamak genellikle hatalı bir ürüne ve kötü kullanıcı deneyimi. Programa katılmak için yeterince erken başlayın test sürümü ve gerçek dünyadaki işlevsellik için tam test kapsamını sunmalıdır. Başlangıç erken aşamada yapılması, güvenlik sorunlarının tasarım kararlarını şekillendirmesini sağlar. Öte yandan, ve izinlerin yalnızca gözlemlenen retlere dayalı olarak kabul edilmesi güvenli bir yaklaşım değildir. Bunu kullan Cihazın güvenlik denetimi gerçekleştirmesi ve davranışlara göre hataları bildirmesi için gereken süre bu tür içeriklerdir.

Mevcut politikayı kaldırın veya silin

Google Haritalar'dan cihaza özel politika oluşturmak için Örneğin:

• Güvenlik denetimi
• Aşırı serbest izin politikası
• Politika boyutunu küçültme
• Geçersiz politika

Temel hizmetler için yapılan retleri ele alma

Temel hizmetler tarafından oluşturulan retler genellikle dosya etiketleme yoluyla ele alınır. Örnek:

avc: denied { open } for pid=1003 comm=”mediaserver” path="/dev/kgsl-3d0”
dev="tmpfs" scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0
tclass=chr_file permissive=1
avc: denied { read write } for pid=1003 name="kgsl-3d0" dev="tmpfs"
scontext=u:r:mediaserver:s0
tcontext=u:object_r:device:s0 tclass=chr_file permissive=1

/dev/kgsl-3d0 doğru bir şekilde etiketlenerek tamamıyla ele alınır. İçinde Bu örnekte tcontext, device. Bu, /dev öğesindeki her öğenin " cihaz" etiketi kullanabilirsiniz. Yalnızca kabul etmek çıktısı da denetim2allow izin veren bir kurala yol açar.

Bu tür sorunları çözmek için dosyaya daha belirgin bir etiket verin. bu durum gpu_device kullanarak kontrol edin. medya sunucusu, 2020'nin ilk çeyreğine kadar gpu_device olarak ayarlanır.

Şurada önceden tanımlanmış türlerle etiketlenmesi gereken, cihaza özgü diğer dosyalar: temel politika:

• cihazları engelleme
• ses sistemleri
• video cihazları
• sensörler
• NFC
• gps_cihazı
• /sys içindeki dosyalar
• /proc içindeki dosyalar

Genel olarak, varsayılan etiketlere izin vermek yanlıştır. Bunların birçoğu bu kullanıcıların izinleri neverallow kurallarına değil, açıkça izin verilmemiş olsa bile en iyi uygulama, belirli bir veri kümesi etiket.

Yeni hizmetleri ve adresi etiketle reddedilenler

Init tarafından başlatılan hizmetlerin kendi SELinux alanlarında çalışması gerekir. İlgili içeriği oluşturmak için kullanılan aşağıdaki örnek, "foo" hizmetini kendi SELinux alanına koyar ve izin verir.

Hizmet, cihazın init.device.rc dosyası olarak:

service foo /system/bin/foo
    class core

1. "foo" adlı yeni alan adı oluşturma
   

   Dosyayı oluşturma device/manufacturer/device-name/sepolicy/foo.te. şu içeriklerle:

   # foo service
   type foo, domain;
   type foo_exec, exec_type, file_type;
   
   init_daemon_domain(foo)
   

   Bu, foo SELinux alanının ilk şablonudur ve tarafından gerçekleştirilen belirli işlemlere dayalı kurallar ekleyebilir.

2. Etiket: /system/bin/foo
   

   Şunları ekleyin: device/manufacturer/device-name/sepolicy/file_contexts:

   /system/bin/foo   u:object_r:foo_exec:s0
   

   Bu işlem, yürütülebilir dosyanın doğru şekilde etiketlenmesini sağlar. Böylece SELinux emin olmanız gerekir.

3. Başlatma ve sistem görüntülerini oluşturup yükleyin.
4. Alan için SELinux kurallarını hassaslaştırın.
   

   Gerekli izinleri belirlemek için retleri kullanın. İlgili içeriği oluşturmak için kullanılan denetim2allow Araç, iyi yönergeler içeriyor, ancak yalnızca politika konusunda bilgi vermek için bahsedeceğim. Yalnızca çıkışı kopyalamayın.

Zorunlu kılma moduna geri dön

İzin verme modunda sorun giderilebilir, ancak zorunlu kılma moduna geri dönülebilir. olabildiğince erken bitirin ve videoda kalmaya çalışın.

Sık yapılan yanlışlar

Yazarken sık yapılan hatalarla ilgili bazı çözümleri aşağıda bulabilirsiniz politikalarından birini devre dışı bırakabilirsiniz.

Olumsuzluğun aşırı kullanımı

Aşağıdaki örnek kural, ön kapıyı kilitleyip kapıdan çıkmadan önce açık pencereler:

allow { domain -untrusted_app } scary_debug_device:chr_file rw_file_perms

Amaç nettir: üçüncü taraf uygulamalar hariç herkes hata ayıklamaya erişebilir olanak tanır.

Kural birkaç açıdan hatalıdır. untrusted_app hariç tutuldu tüm uygulamalar isteğe bağlı olarak bazı hizmetleri çalıştırabileceğinden isolated_app alanı. Benzer şekilde, üçüncü taraf uygulamaları için yeni alanlar AOSP'ye eklenirse scary_debug_device ürününe de erişebilirler. Kural aşırı serbest. Çoğu alan, Google Haritalar'da bu hata ayıklama aracına erişebilirsiniz. Kural, yalnızca erişim gerektiren alan adları için geçerlidir.

Üretimde hata ayıklama özellikleri

Hata ayıklama özellikleri, üretim derlemelerinde mevcut olmamalıdır. politikası.

En basit alternatif, hata ayıklama özelliğine yalnızca SELinux adb root ve gibi eng/userdebug derlemelerinde devre dışı bırakılır adb shell setenforce 0.

Diğer bir güvenli alternatif de hata ayıklama izinlerini bir userdebug_or_eng ifadesini kullanın.

Politika büyüklüğü patlaması

SEAndroid Politikalarının Tanımı cihaz politikası özelleştirmelerindeki artışta endişe verici bir trend olduğunu belirtiyor. Cihaza özel politika, cihaz. %20+ aralığındaki özelleştirmeler, neredeyse kesinlikle ve ölü politikayı gözden geçirin.

Gereksiz büyük politika:

• Politika ramdisk içinde durduğu için hafızaya iki kez isabet ettirilir ve çekirdek belleğine yüklendiğini fark ettim.
• Daha büyük bir önyükleme görüntüsü yaratarak disk alanını boşa harcar.
• Çalışma zamanı politikası arama sürelerini etkiler.

Aşağıdaki örnekte, üreticiye özel gereksinimlerin karşılandığı iki cihaz gösterilmektedir politikası, cihaz üzerindeki politikanın% 50 ve% 40'ını oluşturuyordu. Politika yeniden yazılmış herhangi bir işlev kaybı olmadan önemli güvenlik iyileştirmeleri sağladı; aşağıda gösterilmiştir. (Shmu ve Flounder AOSP cihazları karşılaştırma amacıyla dahil edilmiştir.)

1. Şekil. Cihaza özgü özelliklerin karşılaştırması politika boyutunuz.

Her iki durumda da politika hem boyut hem de sayısı açısından önemli ölçüde küçültülmüştür izinlerin sayısı. Politika boyutunun küçültülmesinin neredeyse tamamı, ve bu izinlerin çoğu büyük olasılıkla audit2allow. Ölü alan adları da her iki cihaz için de bir sorundu.

dac_override özelliğini verme

dac_override reddi, rahatsız edici işlemin sürecin kullanıcı/grup/dünya izinleriyle bir dosyaya erişmeye çalışıyor. Doğru çözüm, dac_override izninin neredeyse hiçbir zaman verilmemesidir. Bunun yerine dosya veya işlemdeki unix izinlerini değiştirin. Örneğin, init, vold ve installd için gerçekten diğer işlemlerin dosyalarına erişmek için UNix dosya izinlerini geçersiz kılma özelliği. Dan Walsh’un blogunu inceleyin sayfasını ziyaret edin.