SELinux politikası yazma

Android Açık Kaynak Projesi (AOSP), tüm Android cihazlarda ortak olan uygulamalar ve hizmetler için sağlam bir temel politika sağlar. AOSP'ye katkıda bulunanlar bu politikayı düzenli olarak hassaslaştırır. Temel politikanın, cihaz üzerindeki nihai politikanın yaklaşık% 90-95'ini oluşturması ve cihaza özgü özelleştirmelerin kalan %5-10'u oluşturması beklenir. Bu makalede, cihaza özgü özelleştirmeler, cihaza özgü politikanın nasıl yazılacağı ve bu süreçte kaçınılması gereken bazı tuzaklar ele alınmaktadır.

Cihazı kullanıma sunma

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

İzin verilen modda çalıştırma

Bir cihaz izin verici modda olduğunda reddedilmeler günlüğe kaydedilir ancak uygulanmaz. İzin verici mod iki nedenden dolayı önemlidir:

  • İzin verilen mod, politikanın etkinleştirilmesinin diğer erken cihaz etkinleştirme görevlerini geciktirmesini önler.
  • Zorunlu ret, diğer retleri maskeleyebilir. Örneğin, dosya erişimi genellikle dizin arama, dosya açma ve ardından dosya okuma işlemlerini içerir. Zorunlu kılma modunda yalnızca dizin araması reddedilir. İzin verici mod, tüm retlerin görülebilmesini sağlar.

Bir cihazı izin verilen moda geçirmenin en basit yolu çekirdek komut satırını kullanmaktır. Bu, cihazın BoardConfig.mk dosyasına eklenebilir: platform/device/<vendor>/<target>/BoardConfig.mk. Komut satırını değiştirdikten sonra make clean, ardından make bootimage'ü gerçekleştirin ve yeni önyükleme görüntüsünü yükleyin.

Ardından, izin verilen modu aşağıdakilerle onaylayın:

adb shell getenforce

İki hafta, genel izin verilen modda kalmak için makul bir süredir. Retlerin çoğunu ele aldıktan sonra tekrar yaptırım moduna geçin ve ortaya çıkan hataları giderin. Hâlâ ret yanıtı veren alanlar veya hâlâ yoğun geliştirme aşamasında olan hizmetler geçici olarak izin verilen moduna geçirilebilir ancak en kısa sürede yeniden zorunlu moduna geçirilmelidir.

Erken zorunlu kıl

Zorunlu kılma modunda, retler hem günlüğe kaydedilir hem de zorunlu kılınır. Cihazınızı mümkün olduğunca erken yaptırım moduna geçirmeniz önerilir. Cihazlara özel politika oluşturmak ve uygulamak için beklemek genellikle hatalı bir ürüne ve kötü bir kullanıcı deneyimine neden olur. Kendi kendine test sürecine dahil olmak ve gerçek kullanımda işlevselliğin tam test kapsamını sağlamak için yeterince erken başlayın. Erken başlamak, güvenlik sorunlarının tasarım kararlarını etkilemesini sağlar. Buna karşılık, yalnızca gözlemlenen retlere dayalı izinler vermek güvenli bir yaklaşım değildir. Bu süreyi, cihazın güvenlik denetimini yapmak ve izin verilmemesi gereken davranışlarla ilgili hata kaydı göndermek için kullanın.

Mevcut politikayı kaldırma veya silme

Yeni bir cihazda sıfırdan cihaza özel politika oluşturmanın bazı avantajları vardır. Örneğin:

Temel hizmetlerle ilgili retleri ele alma

Temel hizmetler tarafından oluşturulan retler genellikle dosya etiketlemeyle 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 şekilde etiketlenerek tamamen giderilmiştir. Bu örnekte tcontext, device değerini alır. Bu, daha spesifik bir etiket atanmadığı sürece /dev içindeki her şeyin " device" etiketini aldığı varsayılan bağlamı temsil eder. Burada audit2allow'un çıktısını kabul etmek, yanlış ve aşırı izin verici bir kurala neden olur.

Bu tür sorunları çözmek için dosyaya daha spesifik bir etiket verin. Bu durumda etiket gpu_device olmalıdır. Temel politikada gpu_device'a erişmek için mediaserver'ın gerekli izinlere zaten sahip olması nedeniyle başka izinlere gerek yoktur.

Temel politikada önceden tanımlanmış türlerle etiketlenmesi gereken cihaza özgü diğer dosyalar:

Genel olarak varsayılan etiketlere izin vermek yanlıştır. Bu izinlerin çoğuna neverallow kuralları tarafından izin verilmez ancak açıkça izin verilmese bile en iyi uygulama, belirli bir etiket sağlamaktır.

Yeni hizmetleri etiketleme ve retleri ele alma

Init tarafından başlatılan hizmetlerin kendi SELinux alanlarında çalışması gerekir. Aşağıdaki örnekte, "foo" hizmeti kendi SELinux alanına yerleştirilmiş ve hizmete izinler verilmiştir.

Hizmet, cihazımızın init.device.rc dosyasında şu şekilde başlatılır:

service foo /system/bin/foo
    class core
  1. "foo" adlı yeni bir alan oluşturun

    Aşağıdaki içeriklerle device/manufacturer/device-name/sepolicy/foo.te dosyasını oluşturun:

    # foo service
type foo, domain;
type foo_exec, exec_type, file_type;

init_daemon_domain(foo)

    Bu, foo SELinux alanının ilk şablonudur. Bu şablona, yürütülebilir dosya tarafından gerçekleştirilen belirli işlemlere göre kurallar ekleyebilirsiniz.

  2. Etiket /system/bin/foo

    Aşağıdakileri device/manufacturer/device-name/sepolicy/file_contexts alanına ekleyin:

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

    Bu, SELinux'un hizmeti doğru alanda çalıştırması için yürütülebilir dosyanın doğru şekilde etiketlendiğinden emin olur.

  3. Başlatma ve sistem görüntülerini derleyip flaşlayın.
  4. Alan için SELinux kurallarını hassaslaştırın.

    Gerekli izinleri belirlemek için retleri kullanın. audit2allow aracı, iyi yönergeler sağlar ancak yalnızca politika yazma sürecinde bilgi edinmek için kullanın. Yalnızca çıkışı kopyalamayın.

Zorunlu kılma moduna geri dönme

İzin verici modda sorun giderebilirsiniz ancak mümkün olduğunca erken bir zamanda zorunlu moduna geri dönüp bu modda kalmaya çalışın.

Sık yapılan yanlışlar

Cihazlara özgü politikalar yazarken yapılan yaygın hatalara yönelik birkaç çözüm aşağıda verilmiştir.

Olumsuzlama ifadelerinin aşırı kullanımı

Aşağıdaki örnek kural, ön kapıyı kilitlemek ancak pencereleri açık bırakmaya benzer:

allow { domain -untrusted_app } scary_debug_device:chr_file rw_file_perms

Amaç açıktır: Üçüncü taraf uygulamaları dışındaki herkes hata ayıklama cihazına erişebilir.

Kuralın birkaç açıdan eksikliği var. Tüm uygulamalar isteğe bağlı olarak isolated_app alanında hizmetler çalıştırabileceğinden untrusted_app alanının hariç tutulması kolaydır. Benzer şekilde, AOSP'ye üçüncü taraf uygulamaları için yeni alanlar eklenirse bu uygulamalar da scary_debug_device'ye erişebilir. Kural çok fazla izin vermektedir. Çoğu alan bu hata ayıklama aracına erişmekten fayda sağlamaz. Kural, yalnızca erişim gerektiren alanlara izin verecek şekilde yazılmış olmalıdır.

Üretimde hata ayıklama özellikleri

Hata ayıklama özellikleri ve politikaları üretim sürümlerinde bulunmamalıdır.

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

Hata ayıklama izinlerini userdebug_or_eng ifadesine eklemek de güvenli bir alternatiftir.

Politika boyutunda patlama

Characterizing SEAndroid Policies in the Wild (Gerçek Hayatta SEAndroid Politikalarını Tanımlama) adlı makalede, cihaz politikası özelleştirmelerinin artmasıyla ilgili endişe verici bir trend açıklanmaktadır. Cihazlara özgü politika, bir cihazda çalışan genel politikanın% 5-10'unu oluşturmalıdır. %20'nin üzerindeki özelleştirmeler neredeyse kesinlikle ayrıcalıklı alanlar ve geçersiz politika içerir.

Gereksiz yere büyük politika:

  • Politika hem ramdisk'te hem de çekirdek belleğine yüklendiğinde bellek üzerinde iki kez etki yapar.
  • Daha büyük bir önyükleme resmi gerektirerek disk alanını boşa harcar.
  • Çalışma zamanı politika arama sürelerini etkiler.

Aşağıdaki örnekte, üreticiye özgü politikanın cihaz üzerindeki politikanın% 50'sini ve% 40'ını oluşturduğu iki cihaz gösterilmektedir. Politikanın yeniden yazılması, aşağıda gösterildiği gibi işlevsellikte herhangi bir kayıp yaşanmadan önemli güvenlik iyileştirmeleri sağladı. (Karşılaştırma için Shamu ve Flounder AOSP cihazları dahil edilmiştir.)

Şekil 1: Güvenlik denetiminden sonra cihaza özgü politika boyutunun karşılaştırması.

Şekil 1. Güvenlik denetiminden sonra cihaza özgü politika boyutunun karşılaştırması.

Her iki durumda da politikanın boyutu ve izin sayısı önemli ölçüde azaltıldı. Politika boyutundaki düşüş neredeyse tamamen gereksiz izinlerin kaldırılmasından kaynaklanmaktadır. Bu izinlerin çoğu, audit2allow tarafından oluşturulan ve politikaya gelişigüzel eklenen kurallardır. Her iki cihazda da ölü alanlar da sorun oluşturuyordu.

dac_override yeteneğini verme

dac_override reddi, soruna neden olan işlemin bir dosyaya yanlış Unix kullanıcı/grup/herkese açık izinleriyle erişmeye çalıştığı anlamına gelir. Doğru çözüm, neredeyse hiçbir zaman dac_override iznini vermemektir. Bunun yerine dosya veya işlemdeki Unix izinlerini değiştirin. init, vold ve installd gibi birkaç alanın, diğer işlemlerin dosyalarına erişmek için Unix dosya izinlerini geçersiz kılma özelliğine gerçekten ihtiyacı vardır. Daha ayrıntılı bilgi için Dan Walsh'ın bloguna göz atın.