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. Önerilen kaynaklar için Destekleyici dokümanlar bölümüne bakın.

Önemli 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ı doğrudan değiştirmemeniz gerekir. Bunun yerine, /device/manufacturer/device-name/sepolicy dizinindeki cihaza özgü politika dosyalarınızı ekleyin veya düzenleyin. Android 8.0 ve sonraki sürümlerde, bu dosyalarda yaptığınız değişiklikler yalnızca tedarikçi dizininizdeki politikayı etkiler. Android 8.0 ve sonraki sürümlerde herkese açık 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ı makaleyi inceleyin. Android sürümünden bağımsız olarak aşağıdaki 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'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 etiketleri belirttiğiniz yerlerdir.

  • 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ükseltmenin bir parçası olarak 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şiklikleri diğer bölümlere yükseltme sırasında da otomatik olarak uygulayabilirsiniz.
  • genfs_contexts, genişletilmiş özellikleri desteklemeyen proc veya vfat gibi dosya sistemlerine etiketler atar. Bu yapılandırma, çekirdek politikasının bir parçası olarak 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 bağlantısının kaldırılıp yeniden kurulması gerekir. context=mount seçeneğini kullanarak belirli etiketler belirli sabitlemelere de atanabilir. Örneğin, vfat
  • property_contexts, hangi süreçlerin bunları ayarlayabileceğini kontrol etmek için Android sistem özelliklerine etiketler atar. Bu yapılandırma, başlangıç sırasında init işlemi tarafından okunur.
  • service_contexts, hizmet için hangi işlemlerin bağlayıcı referansı ekleyebileceğini (kaydedebildiğini) ve bulabileceğini (arama yapabileceğini) kontrol etmek amacıyla Android bağlayıcı hizmetlerine etiketler atar. Bu yapılandırma, başlangıç 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, uygulamaların imzalarına ve isteğe bağlı olarak paket adlarına göre seinfo etiketi atar. 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 alanları, keystore2 daemon'u tarafından zorunlu kılınmıştı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.mkmakefile 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ş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 yaptığınız eklemelere uyum sağlayacak şekilde özelleştirebilir veya mevcut kurulumunuzu Doğrulama bölümünde açıklandığı gibi doğrulayabilirsiniz.

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

Uygulama

SELinux'u kullanmaya başlamak için:

  1. Çekirdekte SELinux'u etkinleştirme: 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ştirilmesidir. İlk önyükleme politikanızı oluşturduktan sonra, cihazınızın politikaları uygulayabilmesi veya CTS'de başarısız olmaması için bu parametreyi kaldırın.
  3. Sistemi izin verici olarak başlatın ve başlatma sırasında hangi reddedmelerle 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ı tanımlayın.
  6. Nesneleriniz için mevcut veya yeni etiketler 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 olarak bu, politikaya uygun mevcut bir etikettir ancak bazen yeni bir etikete ve bu etikete erişim kurallarına ihtiyaç duyulur. 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. Örneğin, init tarafından oluşturulan tüm hizmetlerin kendi Aşağıdaki komutlar, çalışmaya devam edenleri ortaya çıkarmaya yardımcı olur (ancak TÜM hizmetlerin bu şekilde işlem görmesi 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 mount'un her kullanımının doğru şekilde etiketlenmiş bir dosya sistemine karşılık geldiğinden veya bir context= mount seçeneğinin belirtildiğinden emin olun.
  11. Her bir reddi inceleyin ve her birini düzgün şekilde işlemek için SELinux politikası oluşturun. Özelleştirme bölümündeki örneklere bakı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 edinmek ve bu adımlardan bazılarını daha ayrıntılı incelemek 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 dikkate almanız gereken istismar örneklerini aşağıda bulabilirsiniz:

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 giden sembolik bağlantılarla değiştirebilir. Bu da saldırganın rastgele dosyaların üzerine yazmasına olanak tanır. Ancak uygulamanızın hiçbir zaman sembolik bağlantıyı taramadığını biliyorsanız SELinux ile bunu yapmasını yasaklayabilirsiniz.

Sistem dosyaları: Yalnızca sistem sunucusu tarafından değiştirilmesi gereken sistem dosyası 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ş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 sunucusu olur. 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: Kök olarak çalışması gereken ancak uygulama verilerine erişememesi gereken işlev sınıfı da buna örnek olarak verilebilir. Uygulama verileriyle alakalı olmayan belirli alanların internete erişmesinin yasaklanması gibi geniş kapsamlı iddialar yapılabildiğinden bu özellik son derece kullanışlıdır.

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.