SELinux'u uygulama

SELinux varsayılan olarak reddetme moduna ayarlanmıştır. Bu, çekirdekte kanca bulunan her erişime politika tarafından açıkça izin verilmesi gerektiği anlamına gelir. Bu, politika dosyasının kurallar, türler, sınıflar, izinler ve daha fazlasıyla ilgili çok sayıda bilgi içerdiği anlamına gelir. SELinux'un tüm yönlerini ele almak bu dokümanın kapsamı dışındadır ancak yeni Android cihazları kullanıma sunarken politika kurallarının nasıl yazılacağını anlamak artık çok önemlidir. SELinux ile ilgili çok sayıda bilgi mevcuttur. Bkz. Destekleyici dokümanlarına göz atın.

Anahtar dosyalar

SELinux'u etkinleştirmek için en son Android çekirdeğini entegre edin ve ardından system/sepolicy dizinindeki dosyaları dahil edin. Derlendiğinde bu dosyalar SELinux çekirdek güvenlik politikasını içerir ve yayın öncesi Android işletim sistemini kapsar.

Genel olarak, system/sepolicy dosyalarını değiştirmemeniz gerekir. ekleyebilirsiniz. Bunun yerine, cihaza özel politika dosyalarınızı /device/manufacturer/device-name/sepolicy. dizin. Android 8.0 ve sonraki sürümlerde bu dosyalarda yaptığınız değişiklikler yalnızca tedarikçi firma dizininizdeki politikayı etkiler. Paydaşların ayrılmasıyla ilgili daha Android 8.0 ve sonraki sürümlerde herkese açık sepolicy için bkz. Android'de SEPolicy'yi özelleştirme 8.0 ve sonraki sürümler. Android sürümünden bağımsız olarak şu dosyaları değiştirmeye devam edersiniz:

Politika dosyaları

*.te ile biten dosyalar, SELinux politika kaynak dosyalarıdır ve alan adlarını ve etiketlerini tanımlar. /device/manufacturer/device-name/sepolicy'te 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 etiketler belirttiğiniz yerdir.

  • file_contexts, dosyalara etiketler atar ve çeşitli kullanıcı alanı bileşenleri tarafından kullanılır. Yeni politikalar 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'te yapılan değişiklikler yükseltme kapsamında sistem ve kullanıcı verileri bölümlerine otomatik olarak uygulanır. Bölüm, salt okunur/yazılabilir olarak bağlandıktan sonra init.board.rc dosyanıza restorecon_recursive çağrıları ekleyerek değişiklikler diğer bölümlere yükseltme sırasında da otomatik olarak uygulanabilir.
  • genfs_contexts, dosya sistemlerine şunun gibi etiketler atar: Genişletilmiş desteği desteklemeyen proc veya vfat özellikleri hakkında daha fazla bilgi edinin. Bu yapılandırma, çekirdek politikasının bir parçası olarak yüklenir ancak değişiklikler, çekirdek içi düğümlerde uygulanmayabilir, yeniden başlatma veya değişikliği tam olarak uygulamak için dosya sisteminin bağlantısını kesme ve yeniden ekleme. Aşağıdaki gibi bağlantılara da belirli etiketler atanabilir: vfat için context=mount seçeneğini kullanabilirsiniz.
  • property_contexts, hangi süreçlerin bunları ayarlayabileceğini kontrol etmek için Android sistem özelliklerine etiketler atar. Bu yapılandırma Başlatma sırasında init işlem.
  • service_contexts, etiketleri Android bağlayıcı hizmetlerine atar hangi işlemlerin bir bağlayıcı ekleyebileceğini (kaydetebileceğini) ve bulabileceğini (arayacağını) kontrol et bu hizmet için bir referanstır. Bu yapılandırma Başlatma sırasında servicemanager işlem.
  • seapp_contexts, uygulama işlemlerine etiketler atar ve /data/data dizin. Bu yapılandırma Her uygulama başlatma işleminde ve installd tarihine kadar zygote süreci unutmayın.
  • mac_permissions.xml, uygulamalara bir seinfo etiketi atar tercih edebilirsiniz. seinfo etiketi, seinfo etiketine sahip tüm uygulamalara belirli bir etiket atamak için seapp_contexts dosyasında anahtar olarak kullanılabilir. Bu yapılandırma, system_server tarafından başlangıçta okunur.
  • keystore2_key_contexts, Keystore 2.0 ad alanlarına etiketler atar. Bu ad alanı, keystore2 arka plan programı tarafından zorunlu kılınır. Anahtar kasası her zaman UID/AID tabanlı ad alanları sağlamıştır. Keystore 2.0 ayrıca sepolicy tarafından tanımlanan ad alanlarını da zorunlu kılar. Bu dosyanın biçimi ve kurallarının ayrıntılı açıklamasını burada bulabilirsiniz.

BoardConfig.mk makefile

Politika ve bağlam dosyalarını düzenledikten veya ekledikten sonra, /device/manufacturer/device-name/BoardConfig.mk. Makefile ile sepolicy alt dizinine ve her yeni politika dosyasına referans verin. 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 şunlardan birini yapabilirsiniz: SELinux politikalarınızı Android işletim sistemi konusunda açıklandığı gibi Özelleştirme veya mevcut kurulumun Doğrulama.

Yeni politika dosyaları ve BoardConfig.mk güncellemeleri uygulandığında politika ayarları, nihai çekirdek politika dosyasına otomatik olarak eklenir. sepolicy'in cihazda nasıl oluşturulduğuyla ilgili daha fazla bilgi için Site politikası oluşturma.

Uygulama

SELinux'u kullanmaya başlamak için:

  1. Çekirdekteki SELinux'u etkinleştirin: CONFIG_SECURITY_SELINUX=y.
  2. kernel_cmdline veya bootconfig parametresini değiştirerek şunları yapın: 
    BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
    . veya 
    BOARD_BOOTCONFIG := androidboot.selinux=permissive
    Bu yalnızca cihaza yönelik politikanın ilk geliştirme süreciyle ilgilidir. Siz bir başlangıç önyükleme politikanız varsa, veya CTS'yi uygulayamaz.
  3. Sistemi izin verilecek şekilde önyükleyin ve önyükleme sırasında hangi reddetmelerle karşılaşıldığını görün:
    Ubuntu 14.04 veya sonraki 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! ile benzer uyarılar olup olmadığını değerlendirin. Bkz. Talimatlar için doğrulama ve araçlar.
  5. Cihazları ve etiketlenmesi gereken diğer yeni dosyaları tanımlayın.
  6. Nesneleriniz için mevcut veya yeni etiketleri kullanın. Önceden 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 koşullarda bu, politikaya uygun mevcut bir etikettir, ancak bazen Yeni bir etiket gerekir ve bu etikete erişim kuralları gerekir. Etiketlerinizi uygun bağlam dosyalarına ekleyin.
  7. Kendi güvenlik alanlarına sahip olması gereken alanları/süreçleri tanımlayın. Her biri için tamamen yeni bir politika yazmanız gerekebilir. Tümü örneğin init alan adından ortaya çıkan hizmetlerin sahip. Aşağıdaki komutlar, çalışmaya devam eden komutların ortaya çıkarılmasına yardımcı olur (ancak TÜMÜ aşağıdaki hizmetlerin uygulanması gerekir):
    adb shell su -c ps -Z | grep init

    adb shell su -c dmesg | grep 'avc: '
  8. Alan türü olmayan alanları belirlemek için init.device.rc dosyasını inceleyin. init'ye kural eklemekten veya init erişimlerini kendi politikalarındaki erişimlerle karıştırmaktan kaçınmak için geliştirme sürecinizin erken aşamalarında onlara bir alan adı verin.
  9. BOARD_SEPOLICY_* değişkenlerini kullanmak için BOARD_CONFIG.mk öğesini ayarlayın. Bu ayarı yapmayla ilgili ayrıntılar için system/sepolicy'deki README dosyasını inceleyin.
  10. init.device.rc ve fstab.device dosyasını inceleyin ve her mount kullanımının doğru bir şekilde etiketli dosya sistemi veya context= mount seçeneğinin belirtiliyor.
  11. Her redde gözden geçirin ve her birinin doğru şekilde ele alınması için SELinux politikası oluşturun. Görüntüleyin Özelleştirme bölümündeki örneklere göz atın.

AOSP'deki politikalarla başlamalı ve ardından kendi özelleştirmeleriniz için bu politikaları temel almanız gerekir. Politika stratejisi hakkında daha fazla bilgi ve daha ayrıntılı incelemek için bkz. SELinux Politikası yazma.

Kullanım örnekleri

Kendi öykünüzü tasarlarken göz önünde bulundurmanız gereken istismarlara dair spesifik örnekleri burada bulabilirsiniz yazılımı ve ilişkili SELinux politikaları:

Sembolik bağlantılar: Sembolik bağlantılar dosya olarak göründüğü için genellikle dosya olarak okunur. Bu da kötüye kullanımlara neden olabilir. Ö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 bu dosyaları kontrol ettikleri koda yönelik sembolik bağlantılarla değiştirebilir. Bu da saldırganın rastgele dosyaların üzerine yazmasına olanak tanır. Ancak ne yazık ki uygulama sembolik bir bağlantıyı hiçbir zaman aktarmıyorsa bunu engelleyebilirsiniz. daha fazla bilgi edindiniz.

Sistem dosyaları: Kullanılan sistem dosyalarının sınıfını yalnızca sistem sunucusu tarafından değiştirilmelidir. Yine de netd, init ve vold root olarak çalıştırıldığı için bu sistem dosyalarına erişebilir. Bu nedenle, netd'ün güvenliği ihlal edilirse bu dosyalar ve muhtemelen sistem sunucusunun güvenliği de ihlal edilebilir.

SELinux ile bu dosyaları sistem sunucusu veri dosyaları olarak tanımlayabilirsiniz. Bu nedenle, bu dosyalara okuma/yazma erişimi olan tek alan, sistem sunucusudur. netd'nin güvenliği ihlal edilse bile kök olarak çalışsa bile alanları sistem sunucusu alanına geçiremez ve bu sistem dosyalarına erişemez.

Uygulama verileri: Başka bir örnek de kök olarak çalıştırılmalıdır. Bu inanılmaz Alakasız belirli alan adları gibi geniş kapsamlı onaylar yapılabileceği için uygulama verilerine erişimi olması gerekir.

setattr: chmod ve chown gibi komutlar için ilişkili alanın setattr gerçekleştirebileceği dosya grubunu tanımlayabilirsiniz. Bunun dışındaki her şey, root kullanıcısı tarafından bile bu değişikliklerden yasaklanabilir. Bu nedenle, bir uygulama chmod ve chown etiketli app_data_files ile çalışabilir ancak shell_data_files veya system_data_files ile çalışmaz.