SELinux'u uygulama

SELinux, varsayılan olarak erişimi reddedecek şekilde ayarlanır. Bu nedenle, çekirdekte kancası olan her erişimin politika tarafından açıkça izin verilmesi gerekir. Bu, politika dosyasının kurallar, türler, sınıflar, izinler ve daha fazlasıyla ilgili çok miktarda bilgi içerdiği anlamına gelir. SELinux'un tam olarak ele alınması bu belgenin 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 hakkında çok fazla bilgi mevcut. Önerilen kaynaklar için Destekleyici belgeler bölümüne bakın.

Önemli dosyalar

SELinux'u etkinleştirmek için en yeni Android çekirdeğini entegre edin ve ardından system/sepolicy dizinindeki dosyaları dahil edin. 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ştirmemeniz gerekir. Bunun yerine, /device/manufacturer/device-name/sepolicy dizinine cihaza özel politika dosyalarınızı ekleyin veya bu dosyaları düzenleyin. Android 8.0 ve sonraki sürümlerde, bu dosyalarda yaptığınız değişiklikler yalnızca satıcı dizininizdeki politikayı etkilemelidir. Android 8.0 ve sonraki sürümlerde genel sepolicy'nin ayrılması hakkında daha fazla bilgi için Android 8.0 ve sonraki sürümlerde SEPolicy'yi özelleştirme başlıklı makaleye bakın. Android sürümünden bağımsız olarak şu dosyaları değiştirmeye devam edersiniz:

Politika dosyaları

*.te ile biten dosyalar, alanları ve etiketlerini tanımlayan SELinux politika kaynak dosyalarıdır. /device/manufacturer/device-name/sepolicy içinde 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 etiket 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 komutunu çalıştırın. Yükseltmelerde, file_contexts ile ilgili değişiklikler, yükseltme kapsamında sisteme ve kullanıcı verileri bölümlerine otomatik olarak uygulanır. Bölüm okuma/yazma modunda 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 otomatik olarak da uygulanabilir.
  • genfs_contexts, genişletilmiş özellikleri desteklemeyen proc veya vfat gibi dosya sistemlerine etiketler atar. Bu yapılandırma çekirdek politikası kapsamında yüklenir ancak değişiklikler çekirdek içi inode'lar için geçerli olmayabilir. Bu durumda, değişikliğin tam olarak uygulanması için yeniden başlatma veya dosya sisteminin çıkarılıp yeniden bağlanması gerekir. Belirli etiketler, context=mount seçeneği kullanılarak belirli bağlama noktalarına da atanabilir.vfat
  • 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, hizmet için hangi işlemlerin bağlayıcı referansı ekleyebileceğini (kaydedebileceğini) ve bulabileceğini (arama) kontrol etmek amacıyla 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 işlemlerine ve /data/data dizinlerine etiketler atar. Bu yapılandırma, her uygulama başlatıldığında zygote işlemi 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 seinfo etiketi atar. Daha sonra, seinfo etiketine sahip tüm uygulamalara belirli bir etiket atamak için seinfo etiketi, seinfo dosyasında anahtar olarak kullanılabilir.seapp_contexts Bu yapılandırma, başlatma sırasında system_server tarafından okunur.
  • keystore2_key_contexts, Keystore 2 ad alanlarına etiket atar. Bu ad alanları keystore2 daemon'u tarafından zorunlu kılınır. Keystore her zaman UID/AID tabanlı ad alanları sağlamıştır. Keystore 2 ayrıca sepolicy tanımlı ad alanlarını da zorunlu kılar. Bu dosyanın biçimi ve kuralları hakkında ayrıntılı açıklamayı burada bulabilirsiniz.

BoardConfig.mk makefile

Politika ve bağlam dosyalarını düzenledikten veya ekledikten sonra /device/manufacturer/device-name/BoardConfig.mk alt dizinine ve her yeni politika dosyasına referans vermek için sepolicy makefile'ınızı 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ızda SELinux etkinleştirilir. Artık Özelleştirme bölümünde açıklandığı gibi Android işletim sistemine kendi eklemelerinizi yapabilmek için SELinux politikalarınızı özelleştirebilir veya Doğrulama bölümünde ele alındığı gibi mevcut kurulumunuzu doğrulayabilirsiniz.

Yeni politika dosyaları ve BoardConfig.mk güncellemeleri uygulandığında yeni politika ayarları, nihai çekirdek politika dosyasına otomatik olarak eklenir. sepolicy'nin cihazda nasıl oluşturulduğu hakkında daha fazla bilgi için Building sepolicy (sepolicy oluşturma) başlıklı makaleyi inceleyin.

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 cihaz için politikanın ilk geliştirme aşamasında geçerlidir. İlk başlatma politikanız olduktan sonra bu parametreyi kaldırın. Böylece cihazınız CTS'yi zorunlu kılar veya CTS'de başarısız olur.
  3. Sistemi izin verici modda başlatın ve başlatma sırasında 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. Doğrulama bölümüne bakın. Doğrulama bölümüne bakın. Doğrulama bölümüne bakın. Doğrulama bölümüne bakın.<0xx0A> Doğrulama bölümüne bakın. Doğrulama bölümüne bakın. Doğrulama bölümüne bakın. Doğrulama bölümüne bakın. Doğrulama bölümüne bakın. Doğrulama bölümüne bakın. Doğrulama bölümüne bakın. Doğrulama bölümüne bakın. Doğrulama�
  5. Etiketlenmesi gereken cihazları ve diğer yeni dosyaları belirleyin.
  6. Nesneleriniz için mevcut veya yeni etiketler kullanın. Öğelerin daha önce nasıl etiketlendiğini görmek için *_contexts dosyalarına bakın ve etiket anlamları hakkındaki bilgileri kullanarak yeni bir etiket atayın. İdeal olarak bu, politikaya uygun mevcut bir etikettir ancak bazen yeni bir etiket gerekir ve bu etikete erişimle ilgili kurallar oluşturulması gerekir. Etiketlerinizi uygun bağlam dosyalarına ekleyin.
  7. Kendi güvenlik alanlarına sahip olması gereken alanları/işlemleri belirleyin. Büyük olasılıkla her biri için tamamen yeni bir politika yazmanız gerekir. Örneğin, init'dan oluşturulan tüm hizmetlerin kendi hizmetleri olmalıdır. Aşağıdaki komutlar, çalışmaya devam edenleri ortaya çıkarmanıza yardımcı olur (ancak TÜM hizmetlerin bu şekilde ele alınması 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 bölümünü inceleyin. init alanına kural eklememek veya init erişimlerini kendi politikalarındaki erişimlerle karıştırmamak için geliştirme sürecinizin başlarında onlara bir alan verin.
  9. BOARD_SEPOLICY_* değişkenlerini kullanmak için BOARD_CONFIG.mk ayarlayın. Bu ayarı yapmayla ilgili ayrıntılar için system/sepolicy içindeki README dosyasına bakın.
  10. init.device.rc ve fstab.device dosyasını inceleyin ve mount karakterinin her kullanımının düzgün şekilde etiketlenmiş bir dosya sistemiyle eşleştiğinden veya bir context= mount seçeneğinin belirtildiğinden emin olun.
  11. Her bir ret işlemini inceleyin ve her birini uygun şekilde işlemek için SELinux politikası oluşturun. Özelleştirme bölümündeki örnekleri inceleyin.

AOSP'deki politikalarla başlamalı ve ardından kendi özelleştirmeleriniz için bu politikaları temel almalısınız. Politika stratejisi ve bu adımlardan bazılarına daha yakından bakmak için SELinux Politikası Yazma başlıklı makaleyi inceleyin.

Kullanım örnekleri

Kendi yazılımınızı ve ilişkili SELinux politikalarınızı oluştururken göz önünde bulundurmanız gereken belirli istismar örneklerini aşağıda bulabilirsiniz:

Sembolik bağlantılar: Sembolik bağlantılar dosya olarak göründüğünden genellikle dosya olarak okunur. Bu durum, güvenlik açıklarına 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 kodun sembolik bağlantılarıyla değiştirerek rastgele dosyaların üzerine yazabilir. Ancak uygulamanızın hiçbir zaman sembolik bağlantıdan geçmediğ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. Ancak netd, init ve vold root olarak çalıştığından bu sistem dosyalarına erişebilir. Bu nedenle, netd güvenliği ihlal edilirse bu dosyaların ve hatta sistem sunucusunun güvenliği de ihlal edilebilir.

SELinux ile bu dosyaları sistem sunucusu veri dosyaları olarak tanımlayabilirsiniz. Bu nedenle, bunlara okuma/yazma erişimi olan tek alan sistem sunucusudur. netd güvenliği ihlal edilmiş olsa bile, kök olarak çalışmasına rağmen alanları sistem sunucusu alanına geçiremez ve bu sistem dosyalarına erişemez.

Uygulama verileri: Başka bir örnek de root olarak çalışması gereken ancak uygulama verilerine erişmemesi gereken işlev sınıfıdır. Bu, uygulama verileriyle alakasız belirli alan adlarının internete erişmesinin yasaklanması gibi geniş kapsamlı iddialarda bulunulabildiği için son derece faydalıdır.

setattr: chmod ve chown gibi komutlar için, ilişkili alanın setattr işlemini gerçekleştirebileceği dosya grubunu belirleyebilirsiniz. Bu kapsamın dışındaki her şey, kök kullanıcı tarafından bile bu değişikliklerden hariç tutulabilir. Bu nedenle bir uygulama, chmod ve chown olarak etiketlenenlere karşı app_data_files olarak etiketlenenlere karşı çalışabilir ancak shell_data_files veya system_data_files olarak etiketlenenlere karşı çalışamaz.