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. Yenifile_contexts
'ü uygulamak için dosya sistemi görüntüsünü yeniden oluşturun veya yeniden etiketlenecek dosyadarestorecon
'ü ç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ızarestorecon_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 desteklemeyenproc
veyavfat
ö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çincontext=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ındainit
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ındaservicemanager
işlem.seapp_contexts
, uygulama işlemlerine etiketler atar ve/data/data
dizin. Bu yapılandırma Her uygulama başlatma işleminde veinstalld
tarihine kadarzygote
süreci unutmayın.mac_permissions.xml
, uygulamalara birseinfo
etiketi atar tercih edebilirsiniz.seinfo
etiketi,seinfo
etiketine sahip tüm uygulamalara belirli bir etiket atamak içinseapp_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:
- Çekirdekteki SELinux'u etkinleştirin:
CONFIG_SECURITY_SELINUX=y
. - kernel_cmdline veya bootconfig parametresini değiştirerek şunları yapın:
BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
. veyaBOARD_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. - 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
- Çı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. - Cihazları ve etiketlenmesi gereken diğer yeni dosyaları tanımlayın.
- 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. - 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: '
- Alan türü olmayan alanları belirlemek için
init.device.rc
dosyasını inceleyin.init
'ye kural eklemekten veyainit
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. BOARD_SEPOLICY_*
değişkenlerini kullanmak içinBOARD_CONFIG.mk
öğesini ayarlayın. Bu ayarı yapmayla ilgili ayrıntılar içinsystem/sepolicy
'deki README dosyasını inceleyin.- init.device.rc ve fstab.device dosyasını inceleyin ve
her
mount
kullanımının doğru bir şekilde etiketli dosya sistemi veyacontext= mount
seçeneğinin belirtiliyor. - 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.