SELinux'u uygulama

SELinux, varsayılan reddetmeye ayarlanmıştır; bu, çekirdekte bir kancaya sahip olduğu her bir erişime ilke tarafından açıkça izin verilmesi gerektiği anlamına gelir. Bu, bir ilke 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 değerlendirilmesi bu belgenin kapsamı dışındadır, ancak yeni Android cihazları geliştirirken politika kurallarının nasıl yazılacağını anlamak artık çok önemlidir. Halihazırda SELinux ile ilgili çok sayıda bilgi mevcut. Ö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 sistem/sepolicy dizininde bulunan dosyaları birleştirin. Derlendiğinde, bu dosyalar SELinux çekirdek güvenlik politikasını oluşturur ve yukarı akış 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 ilke dosyalarınızı ekleyin veya düzenleyin. Android 8.0 ve sonraki sürümlerde, bu dosyalarda yaptığınız değişikliklerin yalnızca satıcı dizininizdeki politikayı etkilemesi gerekir. Android 8.0 ve sonraki sürümlerde genel sepolicy'nin 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ü ne olursa olsun, yine de şu dosyaları değiştiriyorsunuz:

Politika dosyaları

*.te ile biten dosyalar, etki alanlarını ve etiketlerini tanımlayan SELinux ilke kaynak dosyalarıdır. /device/ manufacturer / device-name /sepolicy içinde yeni ilke 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 etiketler belirlediğiniz yerdir.

  • file_contexts , dosyalara etiketler atar ve çeşitli kullanıcı alanı bileşenleri tarafından kullanılır. Yeni ilkeler oluştururken, 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, restorecon_recursive çağrıları ekleyerek diğer bölümlere yükseltme sırasında otomatik olarak uygulanabilir. board .rc dosyası bölüm monte edildikten sonra okuma-yazma.
  • 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 geçerli olmayabilir, bu da değişikliği tam olarak uygulamak için yeniden başlatmayı veya dosya sisteminin bağlantısını kesmeyi ve yeniden bağlamayı gerektirebilir. context=mount seçeneği kullanılarak vfat gibi belirli bağlamalara belirli etiketler de atanabilir.
  • property_contexts , hangi işlemlerin onları 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 ekleyebileceğini (kaydetebileceğini) ve hizmet için bir bağlayıcı referansı bulabileceğini (aradığını) kontrol etmek için Android bağlayıcı hizmetlerine etiketler atar. Bu yapılandırma, başlatma sırasında servicemanager işlemi tarafından okunur.
  • seapp_contexts , uygulama süreçlerine ve /data/data dizinlerine etiketler atar. Bu yapılandırma, her uygulama açılışında zygote işlemi tarafından ve başlatma sırasında installd tarafından okunur.
  • mac_permissions.xml , imzalarına ve isteğe bağlı olarak paket adlarına göre uygulamalara bir seinfo etiketi atar. seinfo etiketi, o 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 , Etiketleri Keystore 2.0 ad alanlarına atar. Bu ad alanı, keystore2 arka plan programı tarafından zorlanır. Anahtar deposu her zaman UID/AID tabanlı ad alanları sağlamıştır. Anahtar deposu 2.0 ek olarak sepolicy tanımlı ad alanlarını zorlar. Bu dosyanın biçiminin ve kurallarının ayrıntılı bir açıklaması burada bulunabilir.

BoardConfig.mk makefile

İlke ve bağlam dosyalarını düzenledikten veya ekledikten sonra, /device/ manufacturer / device-name /BoardConfig.mk makefile sepolicy alt dizinine ve her yeni ilke dosyasına başvuracak ş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şturma işleminden sonra 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 barındıracak şekilde özelleştirebilir veya Doğrulama kapsamındaki mevcut kurulumunuzu doğrulayabilirsiniz.

Yeni ilke dosyaları ve BoardConfig.mk güncellemeleri yapıldığında, yeni ilke ayarları otomatik olarak son çekirdek ilke dosyasına yerleştirilir. Aygıtta sepolicy'nin nasıl oluşturulduğu hakkında daha fazla bilgi için bkz. sepolicy oluşturma .

uygulama

SELinux'u kullanmaya 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ıt için ilkenin ilk geliştirmesi içindir. İlk önyükleme politikanız olduktan sonra, cihazınızın zorlaması veya CTS'de başarısız olması için bu parametreyi kaldırın.
  3. Sistemi izinli olarak başlatın ve açılışta hangi retlerle karşılaşıldığını görün:
    Ubuntu 14.04 veya daha yeni sürümlerde:
    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. Çıktıyı init: Warning! Service name needs a SELinux domain defined; please fix! Talimatlar ve araçlar için Doğrulama bölümüne bakın.
  5. Etiketlenmesi gereken cihazları ve diğer yeni dosyaları belirleyin.
  6. Nesneleriniz için mevcut veya yeni etiketleri kullanın. Nesnelerin daha önce nasıl etiketlendiğini görmek için *_contexts dosyalarına bakın ve yeni bir etiket atamak için etiket anlamlarını kullanın. İdeal olarak, bu, politikaya uyan 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 bağlam dosyalarına ekleyin.
  7. Kendi güvenlik etki alanlarına sahip olması gereken etki alanlarını/süreçleri belirleyin. Muhtemelen her biri için tamamen yeni bir politika yazmanız gerekecektir. Örneğin init öğesinden oluşturulan tüm hizmetlerin kendilerine ait olması gerekir. Aşağıdaki komutlar, çalışmaya devam edenleri ortaya çıkarmaya yardımcı olur (ancak TÜM hizmetlerin böyle bir tedaviye ihtiyacı vardır):
    adb shell su -c ps -Z | grep init
    tutucu6 l10n-yer
    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 kurallar eklemekten veya init erişimlerini kendi politikalarındakilerle karıştırmaktan kaçınmak için geliştirme sürecinizin başlarında onlara bir etki alanı verin.
  9. BOARD_SEPOLICY_* değişkenlerini kullanmak için BOARD_CONFIG.mk ayarlayın. Bunu ayarlamayla ilgili ayrıntılar için system/sepolicy bakın .
  10. initi inceleyin. device .rc ve fstab. device dosyası oluşturun 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 reddetmeyi gözden geçirin ve her birini uygun şekilde işlemek için SELinux politikası oluşturun. Özelleştirme bölümündeki örneklere bakın.

AOSP'deki ilkelerle başlamalı ve ardından kendi özelleştirmeleriniz için bunları geliştirmelisiniz. Politika stratejisi hakkında daha fazla bilgi ve bu adımlardan bazılarına daha yakından bakmak için bkz. SELinux Politikası Yazma .

Kullanım durumları

Kendi yazılımınızı ve ilgili SELinux politikalarınızı oluştururken göz önünde bulundurmanız gereken belirli açıklardan yararlanma örnekleri şunlardır:

Sembolik bağlantılar - Sembolik bağlantılar dosya olarak göründüğünden, 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ı açık olacak şekilde değiştirir.

Saldırganlar daha sonra bu dosyaları kontrol ettikleri koda sembolik bağlantılarla değiştirerek saldırganın rastgele dosyaların üzerine yazmasına izin verebilir. Ancak uygulamanızın bir sembolik bağlantıyı asla geçmeyeceğini biliyorsanız, bunu SELinux ile yapmasını engelleyebilirsiniz.

Sistem dosyaları - Yalnızca sistem sunucusu tarafından değiştirilmesi gereken sistem dosyalarının sınıfını düşünün. Yine de netd , init ve vold root olarak çalıştığından bu sistem dosyalarına erişebilirler. Dolayısıyla, netd güvenliği ihlal edilirse, bu dosyaları ve potansiyel olarak sistem sunucusunun kendisini tehlikeye atabilir.

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 güvenliği ihlal edilse bile, etki alanlarını sistem sunucusu etki alanına geçiremez ve kök olarak çalışmasına rağmen bu sistem dosyalarına erişemezdi.

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. Uygulama verileriyle ilgisi olmayan belirli alan adlarının internete erişiminin yasaklanması gibi geniş kapsamlı iddialar yapılabileceğinden, bu inanılmaz derecede faydalıdır.

setattr - chmod ve chown gibi komutlar için, ilişkili etki alanının setattr gerçekleştirebileceği dosya kümesini tanımlayabilirsiniz. Bunun dışındaki herhangi bir şey, kök tarafından bile bu değişikliklerden yasaklanabilir. Bu nedenle, bir uygulama chmod çalıştırabilir ve app_data_files etiketli olanlara karşı chown olabilir, ancak shell_data_files veya system_data_files değil.