SELinux Politikasını Yazmak

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 geliştirirler. Temel politikanın, cihazdaki nihai politikanın yaklaşık %90-95'ini oluşturması ve cihaza özel özelleştirmelerin kalan %5-10'u oluşturması bekleniyor. Bu makale, cihaza özel bu özelleştirmelere, cihaza özel politikanın nasıl yazılacağına ve bu süreçte kaçınılması gereken bazı tuzaklara odaklanmaktadır.

Cihaz getirme

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

İzin verilen modda çalıştır

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

  • İzin verilen mod, politika oluşturma işleminin diğer erken cihaz oluşturma görevlerini geciktirmemesini sağlar.
  • Zorunlu bir inkar, diğer inkarları maskeleyebilir. Örneğin, dosya erişimi genellikle bir dizin aramayı, dosyayı açmayı ve ardından dosyanın okunmasını gerektirir. Zorlama modunda yalnızca dizin arama reddi gerçekleşir. İzin verilen mod, tüm reddetmelerin görülmesini sağlar.

Bir aygıtı izin verilen moda sokmanın 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 gerçekleştirin, ardından make bootimage ve yeni önyükleme görüntüsünü flashlayın.

Bundan sonra, izin verilen modu şununla onaylayın:

adb shell getenforce

İki hafta, küresel hoşgörü modunda olmak için makul bir süredir. Reddetmelerin çoğunu giderdikten sonra, zorlama moduna geri dönün ve hataları ortaya çıktıkça giderin. Hâlâ reddetme üreten etki alanları veya hâlâ yoğun geliştirme aşamasında olan hizmetler, geçici olarak izin verilen moda geçirilebilir, ancak bunları mümkün olan en kısa sürede zorunlu kılma moduna geri getirin.

Erken uygula

Zorlama modunda, reddetmeler hem günlüğe kaydedilir hem de uygulanır. Cihazınızı mümkün olduğu kadar erken yaptırım moduna geçirmek en iyi uygulamadır. Cihaza özel politikayı oluşturmayı ve uygulamayı beklemek genellikle hatalı bir ürüne ve kötü bir kullanıcı deneyimine neden olur. Test sürümüne katılmak için yeterince erken başlayın ve gerçek dünya kullanımındaki işlevlerin tam olarak test edildiğinden emin olun. Erken başlamak, güvenlik endişelerinin tasarım kararlarına yön vermesini sağlar. Tam tersine, izinlerin yalnızca gözlemlenen retlere dayalı olarak verilmesi güvenli olmayan bir yaklaşımdır. Bu zamanı cihazın güvenlik denetimini gerçekleştirmek ve izin verilmemesi gereken davranışlara karşı hataları dosyalamak için kullanın.

Mevcut politikayı kaldırın veya silin

Yeni bir cihazda sıfırdan cihaza özel politika oluşturmanın birkaç iyi nedeni vardır; bunlar arasında şunlar yer alır:

Temel hizmetlerin reddedilmesine yönelik adresler

Temel hizmetler tarafından oluşturulan reddetmeler genellikle dosya etiketlemeyle giderilir. Örneğin:

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 düzgün bir şekilde etiketlenerek tamamen giderilir. Bu örnekte tcontext device . Bu, daha spesifik bir etiket atanmadığı sürece /dev içindeki her şeyin " cihaz " etiketini aldığı varsayılan bağlamı temsil eder. Burada sadece denetim2allow'un çıktısını kabul etmek, yanlış ve aşırı hoşgörülü bir kuralla sonuçlanacaktır.

Bu tür bir sorunu çözmek için dosyaya daha spesifik bir etiket verin; bu durumda bu etiket gpu_device olacaktır. Mediaserver'ın temel politikada gpu_device'e erişim için gerekli izinleri zaten olduğundan başka izne gerek yoktur.

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

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

Yeni hizmetleri etiketleyin ve reddedilenleri adresleyin

Init tarafından başlatılan hizmetlerin kendi SELinux etki alanlarında çalışması gerekir. Aşağıdaki örnek, "foo" hizmetini kendi SELinux etki alanına yerleştirir ve ona izinler verir.

Servis cihazımızın init'inde başlatıldı init. device .rc dosyası şu şekildedir:

service foo /system/bin/foo
    class core
  1. Yeni bir alan adı "foo" 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, yürütülebilir dosya tarafından gerçekleştirilen belirli işlemlere dayalı olarak kurallar ekleyebileceğiniz foo SELinux alanı için başlangıç ​​şablonudur.

  2. Etiket /system/bin/foo

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

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

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

  3. Önyükleme ve sistem görüntülerini oluşturun ve flaşlayın.
  4. Etki alanı için SELinux kurallarını hassaslaştırın.

    Gerekli izinleri belirlemek için reddetmeleri kullanın. Audit2allow aracı iyi yönergeler sağlar, ancak bunu yalnızca politika yazımına bilgi sağlamak için kullanın. Sadece çıktıyı kopyalamayın.

Zorlama moduna geri dön

İzin verilen modda sorun gidermek iyidir, ancak mümkün olduğu kadar erken zorlama moduna geri dönün ve orada kalmaya çalışın.

Yaygın hatalar

Cihaza özel politikalar yazarken sık karşılaşılan hatalara yönelik birkaç çözümü burada bulabilirsiniz.

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

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

allow { domain -untrusted_app } scary_debug_device:chr_file rw_file_perms

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

Kural birkaç açıdan kusurludur. untrusted_app hariç tutulması önemsiz bir çözümdür çünkü tüm uygulamalar isteğe bağlı olarak isolated_app etki alanındaki hizmetleri çalıştırabilir. Benzer şekilde, AOSP'ye üçüncü taraf uygulamalar için yeni alan adları eklenirse, onlar da scary_debug_device dosyasına erişim sahibi olacaktır. Kural aşırı hoşgörülüdür. Çoğu alan adı bu hata ayıklama aracına erişimden yararlanamayacaktır. Kuralın yalnızca erişim gerektiren alanlara izin verecek şekilde yazılması gerekirdi.

Üretimdeki hata ayıklama özellikleri

Üretim yapılarında hata ayıklama özellikleri bulunmamalı ve politikaları da olmamalıdır.

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

Başka bir güvenli alternatif, hata ayıklama izinlerini bir userdebug_or_eng ifadesine dahil etmektir.

Politika boyutunda patlama

SEAndroid Politikalarının Vahşi Ortamda Tanımlanması, cihaz politikası özelleştirmelerinin büyümesindeki endişe verici bir eğilimi anlatıyor. Cihaza özel politika, bir cihazda çalışan genel politikanın %5-10'unu oluşturmalıdır. %20+ aralığındaki özelleştirmeler neredeyse kesin olarak aşırı ayrıcalıklı alan adları ve ölü politika içerir.

Gereksiz derecede büyük politika:

  • Politika ramdisk'te yer aldığından ve aynı zamanda çekirdek belleğine yüklendiğinden belleğe çift darbe alır.
  • Daha büyük bir önyükleme görüntüsü gerektirerek disk alanını boşa harcar.
  • Çalışma zamanı ilkesi arama sürelerini etkiler.

Aşağıdaki örnek, üreticiye özel politikanın cihaz üzerindeki politikanın %50 ve %40'ını oluşturduğu iki cihazı göstermektedir. Politikanın yeniden yazılması, aşağıda gösterildiği gibi işlevsellikte hiçbir kayıp olmadan önemli güvenlik iyileştirmeleri sağladı. (AOSP cihazları Shamu ve Flounder karşılaştırma amacıyla dahil edilmiştir.)

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

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

Her iki durumda da politikanın hem boyutu hem de izin sayısı önemli ölçüde azaldı. Politika boyutundaki azalmanın neredeyse tamamı gereksiz izinlerin kaldırılmasından kaynaklanmaktadır; bunların birçoğu büyük olasılıkla audit2allow tarafından oluşturulan ve ayrım gözetmeksizin politikaya eklenen kurallardır. Ölü alanlar her iki cihaz için de bir sorundu.

dac_override özelliğinin verilmesi

dac_override reddi, rahatsız edici sürecin yanlış unix kullanıcı/grup/dünya izinlerine sahip bir dosyaya erişmeye çalıştığı anlamına gelir. Doğru çözüm neredeyse hiçbir zaman dac_override izni vermemektir. Bunun yerine dosya veya işlemdeki unix izinlerini değiştirin . init , vold ve installd gibi birkaç etki alanı, diğer işlemlerin dosyalarına erişmek için gerçekten unix dosya izinlerini geçersiz kılma yeteneğine ihtiyaç duyar. Daha ayrıntılı bir açıklama için Dan Walsh'un bloguna bakın.