SELinux'un uygulanması

SELinux varsayılan reddetmeye ayarlıdır; bu, çekirdekte bir kancaya sahip olduğu her erişime politika tarafından açıkça izin verilmesi gerektiği anlamına gelir. Bu, bir politika dosyasının kurallar, türler, sınıflar, izinler ve daha fazlasıyla ilgili büyük miktarda bilgiden oluştuğu anlamına gelir. SELinux'un tam olarak ele alınması bu belgenin kapsamı dışındadır, ancak yeni Android cihazları geliştirirken politika kurallarının nasıl yazılacağının anlaşılması artık çok önemlidir. SELinux ile ilgili halihazırda pek çok bilgi mevcuttur. Önerilen kaynaklar için Destekleyici belgelere bakın.

Anahtar dosyalar

SELinux'u etkinleştirmek için en son Android çekirdeğini entegre edin ve ardından system/sepolicy dizininde bulunan dosyaları dahil edin. Derlendiğinde bu dosyalar SELinux çekirdek güvenlik politikasını oluşturur ve yukarı akışlı Android işletim sistemini kapsar.

Genel olarak system/sepolicy dosyalarını doğrudan değiştirmemelisiniz. Bunun yerine, /device/ manufacturer / device-name /sepolicy dizinine kendi cihaza özel politika dosyalarınızı ekleyin veya düzenleyin. Android 8.0 ve üzeri sürümlerde, bu dosyalarda yaptığınız değişiklikler yalnızca satıcı dizininizdeki politikayı etkileyecektir. Android 8.0 ve sonraki sürümlerde kamu güvenliğinin ayrılması hakkında daha fazla ayrıntı için bkz. Android 8.0+ Sürümünde SEPolicy'yi Özelleştirme . Android sürümünden bağımsız olarak şu dosyaları değiştirmeye devam ediyorsunuz:

Politika dosyaları

*.te ile biten dosyalar, etki alanlarını ve etiketlerini tanımlayan SELinux ilkesi kaynak dosyalarıdır. /device/ manufacturer / device-name /sepolicy konumunda yeni politika dosyaları oluşturmanız gerekebilir, ancak mümkün olduğunda mevcut dosyaları güncellemeye çalışmalısınız.

Bağlam dosyaları

Bağlam dosyaları, nesneleriniz için etiketleri belirttiğiniz yerdir.

  • file_contexts dosyalara etiketler atar ve çeşitli kullanıcı alanı bileşenleri tarafından kullanılır. Yeni ilkeler oluşturduğunuzda, dosyalara yeni etiketler atamak için bu dosyayı oluşturun veya güncelleyin. Yeni file_contexts uygulamak için dosya sistemi görüntüsünü yeniden oluşturun veya yeniden etiketlenecek dosyada restorecon çalıştırın. Yükseltmelerde, file_contexts yapılan değişiklikler, yükseltmenin bir parçası olarak sisteme ve kullanıcı verileri bölümlerine otomatik olarak uygulanır. Değişiklikler, init'inize restorecon_recursive çağrıları eklenerek diğer bölümlere yükseltme sırasında da otomatik olarak uygulanabilir. board .rc dosyasını bölüm okuma-yazma bağlandıktan sonra kaydedin.
  • genfs_contexts , genişletilmiş öznitelikleri desteklemeyen proc veya vfat gibi dosya sistemlerine etiketler atar. Bu yapılandırma, çekirdek ilkesinin bir parçası olarak yüklenir, ancak değişiklikler çekirdek içi düğümler için etkili olmayabilir; değişikliğin tam olarak uygulanması için yeniden başlatma veya dosya sisteminin bağlantısının kesilip yeniden takılması gerekebilir. context=mount seçeneği kullanılarak vfat gibi belirli montajlara özel etiketler de atanabilir.
  • property_contexts hangi işlemlerin bunları ayarlayabileceğini kontrol etmek için Android sistem özelliklerine etiketler atar. Bu yapılandırma başlatma sırasında init işlemi tarafından okunur.
  • service_contexts hangi işlemlerin hizmet için bir ciltleyici referansı ekleyebileceğini (kaydetebileceğini) ve bulabileceğini (arayabileceğini) kontrol etmek için Android ciltleyici hizmetlerine etiketler atar. Bu konfigürasyon, başlatma sırasında servicemanager işlemi tarafından okunur.
  • seapp_contexts uygulama işlemlerine ve /data/data dizinlerine etiketler atar. Bu yapılandırma, her uygulama başlatıldığında zygote işlemi tarafından ve başlatma sırasında installd tarafından okunur.
  • mac_permissions.xml uygulamalara imzalarına ve isteğe bağlı olarak paket adlarına göre bir seinfo etiketi atar. Daha sonra seinfo etiketi, bu seinfo etiketine sahip tüm uygulamalara belirli bir etiket atamak için seapp_contexts dosyasında bir anahtar olarak kullanılabilir. Bu yapılandırma başlatma sırasında system_server tarafından okunur.
  • keystore2_key_contexts Keystore 2.0 ad alanlarına etiket atar. Bu ad alanı, anahtar deposu2 arka plan programı tarafından uygulanır. Anahtar deposu her zaman UID/AID tabanlı ad alanları sağlamıştır. Keystore 2.0 ayrıca sepolicy tanımlı ad alanlarını da zorunlu kılar. Bu dosyanın formatı ve kurallarına ilişkin ayrıntılı bir açıklamayı burada bulabilirsiniz.

BoardConfig.mk make dosyası

Politika ve içerik dosyalarını düzenledikten veya ekledikten sonra, /device/ manufacturer / device-name /BoardConfig.mk makefile dosyanızı sepolicy alt dizinine ve her yeni politika dosyasına referans verecek şekilde güncelleyin. BOARD_SEPOLICY değişkenleri hakkında daha fazla bilgi için system/sepolicy/README dosyasına bakın.

BOARD_SEPOLICY_DIRS += \
        <root>/device/manufacturer/device-name/sepolicy

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

Yeniden oluşturmanın ardından cihazınız SELinux ile etkinleştirilir. Artık SELinux politikalarınızı, Özelleştirme bölümünde açıklandığı gibi Android işletim sistemine kendi eklemelerinizi karşılayacak şekilde özelleştirebilir veya Doğrulama bölümünde anlatıldığı gibi mevcut kurulumunuzu doğrulayabilirsiniz.

Yeni politika dosyaları ve BoardConfig.mk güncellemeleri mevcut olduğunda, yeni politika ayarları otomatik olarak son çekirdek politika dosyasına yerleştirilir. Cihazda sepolitikanın nasıl oluşturulduğu hakkında daha fazla bilgi için bkz. Sepolitik oluşturma .

Uygulama

SELinux'a başlamak için:

  1. Çekirdekte SELinux'u etkinleştirin: CONFIG_SECURITY_SELINUX=y
  2. Kernel_cmdline veya bootconfig parametresini şu şekilde değiştirin:
    BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
    veya
    BOARD_BOOTCONFIG := androidboot.selinux=permissive
    Bu yalnızca aygıta ilişkin ilkenin ilk geliştirilmesi içindir. Başlangıç ​​önyükleme politikanızı oluşturduktan sonra, cihazınızın uygulayabilmesi için bu parametreyi kaldırın, aksi takdirde CTS'de başarısız olur.
  3. Sistemi izin verilen şekilde başlatın ve önyükleme sırasında hangi reddetmelerle karşılaşıldığını görün:
    Ubuntu 14.04 veya daha yenisinde:
    adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy
    
    Ubuntu 12.04'te:
    adb pull /sys/fs/selinux/policy
    adb logcat -b all | audit2allow -p policy
    
  4. Çıkışı init: Warning! Service name needs a SELinux domain defined; please fix! Talimatlar ve araçlar için Doğrulama konusuna bakın.
  5. Etiketleme gerektiren cihazları ve diğer yeni dosyaları belirleyin.
  6. Nesneleriniz için mevcut veya yeni etiketleri kullanın. Nesnelerin önceden nasıl etiketlendiğini görmek için *_contexts dosyalarına bakın ve yeni bir etiket atamak için etiket anlamlarına ilişkin bilginizi kullanın. İdeal durumda bu, politikaya uyacak mevcut bir etiket olacaktır, ancak bazen yeni bir etikete ihtiyaç duyulacak ve bu etikete erişim için kurallara ihtiyaç duyulacaktır. Etiketlerinizi uygun içerik dosyalarına ekleyin.
  7. Kendi güvenlik etki alanlarına sahip olması gereken etki alanlarını/işlemleri belirleyin. Muhtemelen her biri için tamamen yeni bir politika yazmanız gerekecektir. Örneğin init oluşturulan tüm hizmetlerin kendilerine ait olması gerekir. Aşağıdaki komutlar, çalışmaya devam edenlerin ortaya çıkarılmasına yardımcı olur (ancak TÜM hizmetlerin böyle bir tedaviye ihtiyacı vardır):
    adb shell su -c ps -Z | grep init
    
    adb shell su -c dmesg | grep 'avc: '
    
  8. init. device .rc etki alanı türü olmayan tüm etki alanlarını tanımlamak için init. device .rc . init kural eklemekten veya init erişimlerini kendi ilkelerindekilerle karıştırmaktan kaçınmak için onlara geliştirme sürecinizin başlarında bir alan adı verin.
  9. BOARD_CONFIG.mk dosyasını BOARD_SEPOLICY_* değişkenlerini kullanacak şekilde ayarlayın. Bunun ayarlanmasıyla ilgili ayrıntılar için system/sepolicy README dosyasına bakın.
  10. Girişi inceleyin. device .rc ve fstab. device dosyasına bakın ve her mount kullanımının uygun şekilde etiketlenmiş bir dosya sistemine karşılık geldiğinden veya bir context= mount seçeneğinin belirtildiğinden emin olun.
  11. Her reddin üzerinden geçin ve her birini doğru şekilde ele almak için SELinux politikası oluşturun. Özelleştirme bölümündeki örneklere bakın.

AOSP'deki politikalarla başlamalı ve daha sonra kendi özelleştirmeleriniz için bunları geliştirmelisiniz. Politika stratejisi hakkında daha fazla bilgi almak ve bu adımların bazılarına daha yakından bakmak için bkz . SELinux Politikasını Yazmak .

Kullanım örnekleri

Kendi yazılımınızı ve ilgili SELinux politikalarınızı oluştururken göz önünde bulundurmanız gereken belirli istismar örnekleri:

Sembolik bağlantılar - Sembolik bağlantılar dosya olarak göründüklerinden genellikle dosya olarak okunurlar ve bu da istismarlara yol açabilir. Örneğin, init gibi bazı ayrıcalıklı bileşenler, belirli dosyaların izinlerini bazen aşırı derecede açık olacak şekilde değiştirir.

Saldırganlar daha sonra bu dosyaları kontrol ettikleri kodlara ait sembolik bağlantılarla değiştirerek saldırganın rastgele dosyaların üzerine yazmasına olanak tanıyabilir. Ancak uygulamanızın hiçbir zaman bir sembolik bağlantıdan geçmeyeceğini biliyorsanız, SELinux ile bunu yapmasını engelleyebilirsiniz.

Sistem dosyaları - Yalnızca sistem sunucusu tarafından değiştirilmesi gereken sistem dosyalarının sınıfını göz önünde bulundurun. Yine de netd , init ve vold root olarak çalıştığından bu sistem dosyalarına erişebilirler. Yani netd güvenliği ihlal edilirse, bu dosyalar ve potansiyel olarak sistem sunucusunun kendisi tehlikeye girebilir.

SELinux ile bu dosyaları sistem sunucusu veri dosyaları olarak tanımlayabilirsiniz. Bu nedenle bunlara okuma/yazma erişimi olan tek etki alanı sistem sunucusudur. netd tehlikeye girse bile, root olarak çalışmasına rağmen etki alanlarını sistem sunucusu etki alanına değiştiremez ve bu sistem dosyalarına erişemez.

Uygulama verileri - Başka bir örnek, kök olarak çalışması gereken ancak uygulama verilerine erişmemesi gereken işlevler sınıfıdır. Bu, uygulama verileriyle ilgisi olmayan belirli alan adlarının internete erişiminin yasaklanması gibi geniş kapsamlı iddialarda bulunulabileceği için inanılmaz derecede faydalıdır.

setattr - chmod ve chown gibi komutlar için, ilgili etki alanının setattr yürütebileceği dosya kümesini tanımlayabilirsiniz. Bunun dışındaki herhangi bir şey, kökten bile olsa, bu değişikliklerden men edilebilir. Dolayısıyla bir uygulama, app_data_files etiketli olanlara karşı chmod ve chown çalıştırabilir ancak shell_data_files veya system_data_files çalıştıramaz.