SELinux'u özelleştirme

Koleksiyonlar ile düzeninizi koruyun İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.

SELinux işlevinin temel düzeyini entegre edip sonuçları ayrıntılı bir şekilde analiz ettikten sonra, Android işletim sisteminde yaptığınız özelleştirmeleri kapsayacak şekilde kendi politika ayarlarınızı ekleyebilirsiniz. Bu politikalar, Android Uyumluluk Programı şartlarını karşılamalı ve varsayılan SELinux ayarlarını kaldırmamalıdır.

Üreticiler mevcut SELinux politikasını kaldırmamalıdır. Aksi takdirde, Android SELinux uygulamasının ve yönettiği uygulamaların bozulma riski vardır. Uyumlu ve çalışır durumda olmak için muhtemelen iyileştirilmesi gereken üçüncü taraf uygulamaları da buna dahildir. Uygulamaların, SELinux özellikli cihazlarda çalışmaya devam edebilmesi için herhangi bir değişiklik gerektirmemesi gerekir.

SELinux'u özelleştirmeye başlarken şunları unutmayın:

• Tüm yeni daemon'lar için SELinux politikası yazma
• Uygun olduğunda önceden tanımlanmış alanları kullanın
• init hizmeti olarak oluşturulan herhangi bir işleme alan adı atama
• Politika yazmadan önce makroları öğrenin
• Temel politikadaki değişiklikleri AOSP'ye gönderme

Aşağıdakileri yapmamaya dikkat edin:

• Uyumsuz politika oluşturma
• Son kullanıcı politikasının özelleştirilmesine izin verme
• MDM politikası özelleştirmelerine izin verme
• Politika ihlalleriyle kullanıcıları korkutma
• Arka kapı ekleme

Spesifik gereksinimler için Android Uyumluluk Tanımı belgesinin Çekirdek Güvenlik Özellikleri bölümüne bakın.

SELinux, beyaz liste yaklaşımını kullanır. Bu, tüm erişimlerin verilmesi için politikada açıkça izin verilmesi gerektiği anlamına gelir. Android'in varsayılan SELinux politikası zaten Android Açık Kaynak Projesi'ni desteklediğinden SELinux ayarlarını herhangi bir şekilde değiştirmeniz gerekmez. SELinux ayarlarını özelleştirirseniz mevcut uygulamaların çalışmasını engellememeye dikkat edin. Başlamak için:

1. En güncel Android çekirdeğini kullanın.
2. En az ayrıcalık ilkesini benimseyin.
3. Yalnızca Android'e yaptığınız eklemeleri ele alın. Varsayılan politika, Android Açık Kaynak Projesi kod tabanıyla otomatik olarak çalışır.
4. Yazılım bileşenlerini tek bir görevi yerine getiren modüllere ayırın.
5. Bu görevleri alakasız işlevlerden ayıran SELinux politikaları oluşturun.
6. Bu politikaları /device/manufacturer/device-name/sepolicy dizinindeki *.te dosyalarına (SELinux politika kaynak dosyalarının uzantısı) koyun ve derlemenize dahil etmek için BOARD_SEPOLICY değişkenlerini kullanın.
7. Yeni alanları başlangıçta izin verici yapın. Bu işlem, alanın .te dosyasında izin verici bir beyan kullanılarak yapılır.
8. Sonuçları analiz edin ve alan tanımlarınızı hassaslaştırın.
9. userdebug derlemelerinde başka ret görünmediğinde izin verici beyanı kaldırın.

SELinux politika değişikliğinizi entegre ettikten sonra, SELinux uyumluluğunun devam etmesini sağlamak için geliştirme iş akışınıza bir adım ekleyin. İdeal bir yazılım geliştirme sürecinde SELinux politikası yalnızca yazılım modeli değiştiğinde değişir, gerçek uygulamada değişiklik olmaz.

SELinux'u özelleştirmeye başlarken önce Android'e eklediğiniz öğeleri denetleyin. Yeni bir işlev yürüten bir bileşen eklediyseniz zorunlu kılma modunu etkinleştirmeden önce bileşenin Android'in güvenlik politikası ve OEM tarafından oluşturulan ilişkili politikalara uyduğundan emin olun.

Gereksiz sorunları önlemek için, cihaz işlevlerinin bozulmasına neden olan çok kısıtlayıcı ve uyumsuz olmaktan ziyade çok geniş kapsamlı ve çok uyumlu olmak daha iyidir. Buna karşılık, değişiklikleriniz başkalarına fayda sağlayacaksa varsayılan SELinux politikasındaki değişiklikleri yama olarak göndermeniz gerekir. Yama varsayılan güvenlik politikasına uygulanırsa her yeni Android sürümünde bu değişikliği yapmanız gerekmez.

Örnek politika beyanları

SELinux, M4 bilgisayar diline dayanır ve bu nedenle zaman kazanmak için çeşitli makroları destekler.

Aşağıdaki örnekte, tüm alanlara /dev/null'ten okuma veya yazma ve /dev/zero'ten okuma erişimi verilir.

# Allow read / write access to /dev/null
allow domain null_device:chr_file { getattr open read ioctl lock append write};

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file { getattr open read ioctl lock };

Aynı ifade, SELinux *_file_perms makrolarıyla (kısayol) yazılabilir:

# Allow read / write access to /dev/null
allow domain null_device:chr_file rw_file_perms;

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file r_file_perms;

Örnek politika

Aşağıda, DHCP için incelediğimiz eksiksiz bir örnek politika verilmiştir:

type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;

init_daemon_domain(dhcp)
net_domain(dhcp)

allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)

type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;

allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };

Örneği inceleyelim:

İlk satırda, tür beyanında DHCP daemon, temel güvenlik politikasından (domain) devralır. Önceki ifade örneklerinden DHCP, /dev/null dosyasını okuyabilir ve bu dosyaya yazabilir.

İkinci satırda DHCP, izin veren bir alan olarak tanımlanır.

init_daemon_domain(dhcp) satırında politika, DHCP'nin init tarafından oluşturulduğunu ve onunla iletişim kurmasına izin verildiğini belirtir.

net_domain(dhcp) satırında politika, DHCP'nin net alanındaki TCP paketlerini okuma ve yazma, soket üzerinden iletişim kurma ve DNS istekleri gönderme gibi ortak ağ işlevlerini kullanmasına izin verir.

allow dhcp proc_net:file write; satırında, DHCP'nin /proc içindeki belirli dosyalara yazabileceği belirtiliyor. Bu satır, SELinux'un ayrıntılı dosya etiketlemesini gösterir. Yazma erişimini yalnızca /proc/sys/net altındaki dosyalarla sınırlandırmak için proc_net etiketini kullanır.

Örneğin allow dhcp netd:fd use; ile başlayan son bloğu, uygulamaların birbiriyle nasıl etkileşime girmesine izin verilebileceğini gösterir. Politikada, DHCP ve netd'nin dosya tanımlayıcıları, FIFO dosyaları, veri paketi soketleri ve UNIX akış soketleriyle birbirleriyle iletişim kurabileceği belirtilmektedir. DHCP, yalnızca veri paketi soketlerini ve UNIX akış soketlerini okuyabilir ve bu soketlere yazabilir, ancak bunları oluşturamaz veya açamaz.

Kullanılabilen kontroller

ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton

add_name remove_name reparent search rmdir open audit_access execmod

ioctl read write create getattr setattr lock relabelfrom relabelto append bind
connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg
name_bind

mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget

fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched
getsession getpgid setpgid getcap setcap share getattr setexec setfscreate
noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem
execstack execheap setkeycreate setsockcreate

compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy

chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap
linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock
ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin
sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write
audit_control setfcap

neverallow kuralları

SELinux neverallow kuralları, hiçbir zaman gerçekleşmemesi gereken davranışları yasaklar. Uyumluluk testiyle birlikte SELinux neverallow kuralları artık cihazlarda zorunlu kılınıyor.

Aşağıdaki kurallar, üreticilerin özelleştirme sırasında neverallow kurallarıyla ilgili hatalardan kaçınmasına yardımcı olmayı amaçlamaktadır. Burada kullanılan kural numaraları Android 5.1'e karşılık gelir ve sürüme göre değişiklik gösterebilir.

Kural 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
ptrace için man sayfasına bakın. sys_ptrace yeteneği, herhangi bir işlemi ptrace etme olanağı tanır. Bu, diğer işlemler üzerinde çok fazla kontrol sağlar ve yalnızca kuralda belirtilen belirli sistem bileşenlerine ait olmalıdır. Bu özelliğin gerekliliği genellikle kullanıcılara yönelik derlemeler için tasarlanmamış bir şeyin veya gerekmeyen bir işlevin varlığını gösterir. Gereksiz bileşeni kaldırın.

Kural 76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
Bu kural, sistemde rastgele kod çalıştırılmasını önlemek için tasarlanmıştır. Daha açık belirtmek gerekirse, yalnızca /system üzerindeki kodun yürütüldüğünü iddia eder. Bu, doğrulanmış başlatma gibi mekanizmalar sayesinde güvenlik garantileri sağlar. Bu neverallow kuralıyla ilgili bir sorunla karşılaşıldığında genellikle en iyi çözüm, soruna neden olan kodu /system bölümüne taşımaktır.

Android 8.0 ve sonraki sürümlerde SEPolicy'yi özelleştirme

Bu bölümde, Android 8.0 ve sonraki sürümlerde tedarikçi SELinux politikası ile ilgili yönergeler ve Android Açık Kaynak Projesi (AOSP) SEPolicy ve SEPolicy uzantılarıyla ilgili ayrıntılar sağlanmaktadır. SELinux politikasının bölümler ve Android sürümleri arasında nasıl uyumlu tutulduğu hakkında daha fazla bilgi için Uyumluluk bölümüne bakın.

Politika yerleşimi

Android 7.0 ve önceki sürümlerde cihaz üreticileri, farklı cihaz türlerinde AOSP politikasını geliştirmeyi amaçlayan politikalar da dahil olmak üzere BOARD_SEPOLICY_DIRS'e politika ekleyebilirdi. Android 8.0 ve sonraki sürümlerde BOARD_SEPOLICY_DIRS alanına politika eklemek, politikayı yalnızca tedarikçi firma resmine yerleştirir.

Android 8.0 ve sonraki sürümlerde politika, AOSP'de aşağıdaki konumlarda bulunur:

• system/sepolicy/public. Tedarikçiye özgü politikada kullanılmak üzere dışa aktarılan politikayı içerir. Tüm bilgiler Android 8.0 uyumluluk altyapısına aktarılır. Herkese açık politika, özelleştirilmiş politikanıza /public dahil edebileceğiniz her şeyi ekleyebilmeniz için sürümler arasında devam eder. Bu nedenle, /public alanına yerleştirilebilecek politika türü daha kısıtlıdır. Bu, platformun dışa aktarılan politika API'sidir: /system ile /vendor arasındaki arayüzle ilgili her şey buraya aittir.
• system/sepolicy/private. Sistem resminin çalışması için gerekli olan ancak tedarikçi firma resim politikasının bilgisinin olmadığı politikayı içerir.
• system/sepolicy/vendor. /vendor içine yerleştirilen ancak temel platform ağacında bulunan (cihaza özgü dizinlerde değil) bileşenlerle ilgili politikayı içerir. Bu, derleme sisteminin cihazlar ile genel bileşenler arasındaki ayrımından kaynaklanan bir yapıdır. Kavramsal olarak bu, aşağıda açıklanan cihaza özel politikanın bir parçasıdır.
• device/manufacturer/device-name/sepolicy. Cihaza özgü politikayı içerir. Politikadaki cihaz özelleştirmelerini de içerir. Android 8.0 ve sonraki sürümlerde bu, tedarikçi firma resmindeki bileşenlerle ilgili politikaya karşılık gelir.

Android 11 ve sonraki sürümlerde system_ext ve ürün bölümleri, bölüme özel politikalar da içerebilir. system_ext ve ürün politikaları da herkese açık ve özel olarak ayrılır. Tedarikçi firmalar, sistem politikası gibi system_ext ve ürünün herkese açık politikalarını kullanabilir.

• SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS. Satıcıya özgü politikada kullanılmak üzere dışa aktarılan politikayı içerir. system_ext bölümüne yüklenir.
• SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS. system_ext görüntüsünün çalışması için gerekli olan ancak tedarikçi firma görüntüsünün politikasında bulunmaması gereken politikayı içerir. system_ext bölümüne yüklenir.
• PRODUCT_PUBLIC_SEPOLICY_DIRS. Satıcıya özgü politikada kullanılmak üzere dışa aktarılan politikayı içerir. Ürün bölümüne yüklenir.
• PRODUCT_PRIVATE_SEPOLICY_DIRS. Ürün resminin işleyişi için gerekli olan ancak satıcı resim politikasının bilgisinin olmadığı politikayı içerir. Ürün bölümüne yüklenir.

Desteklenen politika senaryoları

Android 8.0 ve sonraki sürümlerin yüklü olduğu cihazlarda tedarikçi firma resmi, OEM sistem resmi ve Google tarafından sağlanan referans AOSP sistem resmiyle çalışmalıdır (ve bu referans resimde CTS'yi geçmelidir). Bu şartlar, çerçeve ile tedarikçi kodu arasında net bir ayrım olmasını sağlar. Bu tür cihazlar aşağıdaki senaryoları destekler.

vendor-image-only extensions

Örnek: Satıcı görüntüsünden vndservicemanager'e satıcı görüntüsünde işlemleri destekleyen yeni bir hizmet ekleme.

Önceki Android sürümleriyle kullanıma sunulan cihazlarda olduğu gibi, device/manufacturer/device-name/sepolicy dosyasına cihaza özel özelleştirmeler ekleyin. Tedarikçi bileşenlerinin yalnızca diğer tedarikçi bileşenleriyle etkileşimini düzenleyen yeni politika yalnızca device/manufacturer/device-name/sepolicy içinde bulunan türleri içermelidir. Burada yazılan politika, tedarikçideki kodun çalışmasına izin verir, yalnızca çerçeve OTA'sı kapsamında güncellenmez ve referans AOSP sistem görüntüsüne sahip bir cihazdaki birleşik politikada bulunur.

AOSP ile çalışmak için tedarikçi firma resmi desteği

Örnek: AOSP tarafından tanımlanan bir HAL'i uygulayan yeni bir işlem (tedarikçi firma görüntüsünden hwservicemanager ile kaydedilir) ekleme.

Önceki Android sürümleriyle kullanıma sunulan cihazlarda olduğu gibi, device/manufacturer/device-name/sepolicy'te cihaza özel özelleştirmeler yapın. system/sepolicy/public/ kapsamında dışa aktarılan politika kullanılabilir ve tedarikçi politikasının bir parçası olarak gönderilir. Herkese açık politikadaki türler ve özellikler, sağlanan neverallowsınırlamalara tabi olarak yeni tedarikçiye özgü bitlerle etkileşimleri belirten yeni kurallarda kullanılabilir. Yalnızca tedarikçi firma durumunda olduğu gibi, buradaki yeni politika yalnızca çerçeve OTA'sı kapsamında güncellenmez ve referans AOSP sistem resmine sahip bir cihazdaki birleşik politikada bulunur.

yalnızca sistem görüntüsü uzantıları

Örnek: Yalnızca sistem görüntüsünden diğer işlemler tarafından erişilen yeni bir hizmet (servicemanager'a kayıtlı) ekleme.

Bu politikayı system/sepolicy/private'e ekleyin. İş ortağı sistem görüntüsünde işlevselliği etkinleştirmek için ek işlemler veya nesneler ekleyebilirsiniz. Bunun için bu yeni bitlerin tedarikçi firma görüntüsünde yeni bileşenlerle etkileşime geçmesi gerekmez (özellikle, bu tür işlemler veya nesneler tedarikçi firma görüntüsünün politikası olmadan tam olarak çalışmalıdır). system/sepolicy/public tarafından dışa aktarılan politika, yalnızca satıcı resim uzantılarında olduğu gibi burada da kullanılabilir. Bu politika, sistem görüntüsünün bir parçasıdır ve yalnızca çerçeve OTA'sında güncellenebilir ancak referans AOSP sistem görüntüsü kullanılırken mevcut olmaz.

Genişletilmiş AOSP bileşenlerini sunan vendor-image uzantıları

Örnek: AOSP sistem görüntüsünde de bulunan genişletilmiş istemciler tarafından kullanılmak üzere AOSP dışı yeni bir HAL (ör. genişletilmiş system_server).

Sistem ile tedarikçi arasındaki etkileşim politikası, tedarikçi bölümünde gönderilen device/manufacturer/device-name/sepolicy dizinlerine dahil edilmelidir. Bu, referans AOSP resmiyle çalışmak için tedarikçi firma resmi desteği eklemeyle ilgili yukarıdaki senaryoya benzer. Bununla birlikte, değiştirilmiş AOSP bileşenlerinin sistem bölümünün geri kalanıyla düzgün çalışması için ek politika da gerekebilir (herkese açık AOSP tür etiketlerine sahip oldukları sürece bu sorun oluşturmaz).

Herkese açık AOSP bileşenlerinin yalnızca sistem resmi uzantılarıyla etkileşimi için politika system/sepolicy/private olmalıdır.

Yalnızca AOSP arayüzlerine erişen sistem resmi uzantıları

Örnek: AOSP dışındaki yeni bir sistem işlemi, AOSP'nin kullandığı bir HAL'e erişmelidir.

Bu, yalnızca sistem resmi uzantısı örneğine benzer. Bununla birlikte, yeni sistem bileşenleri system/vendor arayüzünde etkileşim kurabilir. Yeni sistem bileşeninin politikası system/sepolicy/private'e eklenmelidir. Bu, system/sepolicy/public'te AOSP tarafından zaten oluşturulmuş bir arayüz üzerinden yapıldığında kabul edilir (yani işlevsellik için gereken türler ve özellikler oradadır). Politika, cihaza özgü politikaya dahil edilebilir ancak yalnızca çerçeve güncellemesi sonucunda diğer system/sepolicy/private türlerini kullanamaz veya politikaları etkileyecek şekilde değiştirilemez. Politika, yalnızca çerçeve içeren bir OTA'da değiştirilebilir ancak AOSP sistem görüntüsü kullanıldığında (yeni sistem bileşeni de bu görüntüde bulunmaz) mevcut olmaz.

Yeni sistem bileşenleri sunan tedarikçi firma resim uzantıları

Örnek: AOSP analogu olmadan bir istemci işlemi tarafından kullanılmak üzere AOSP olmayan yeni bir HAL ekleme (bu nedenle kendi alanı gerekir).

AOSP-extensions örneğine benzer şekilde, sistem ile tedarikçi arasındaki etkileşimlerle ilgili politika, tedarikçi bölümünde gönderilen device/manufacturer/device-name/sepolicy dizinine yerleştirilmelidir (sistem politikasının tedarikçiye özgü ayrıntılar hakkında bilgi sahibi olmaması için). system/sepolicy/public'te politikayı genişleten yeni herkese açık türler ekleyebilirsiniz. Bu işlem yalnızca mevcut AOSP politikasına ek olarak yapılmalıdır. Yani AOSP herkese açık politikasını kaldırmayın. Yeni herkese açık türler daha sonra system/sepolicy/private ve device/manufacturer/device-name/sepolicy'teki politika için kullanılabilir.

system/sepolicy/public öğesine her eklemenin, eşleme dosyasında izlenmesi gereken ve diğer kısıtlamalara tabi olan yeni bir uyumluluk garantisi sunarak karmaşıklığı artırdığını unutmayın. system/sepolicy/public yalnızca yeni türler ve ilgili izin kuralları eklenebilir; özellikler ve diğer politika beyanları desteklenmez. Ayrıca, yeni herkese açık türler /vendor politikasındaki nesneleri doğrudan etiketlemek için kullanılamaz.

Desteklenmeyen politika senaryoları

Android 8.0 ve sonraki sürümleri çalıştıran cihazlar aşağıdaki politika senaryosuna ve örneklerine destek vermez.

Yalnızca çerçeve OTA'sından sonra yeni tedarikçi firma görüntü bileşenlerine izin gerektiren sistem görüntüsüne ek uzantılar

Örnek: Bir sonraki Android sürümüne, kendi alanını gerektiren ve AOSP dışında yeni bir HAL'e erişmesi gereken yeni bir AOSP dışı sistem işlemi eklenir.

Yeni (AOSP olmayan) sistem ve tedarikçi bileşenleri etkileşimine benzer. Bunun tek farkı, yeni sistem türünün yalnızca çerçeve OTA'sında kullanıma sunulmasıdır. Yeni tür, system/sepolicy/public'teki politikaya eklenebilir ancak mevcut tedarikçi politikası yalnızca Android 8.0 sistem kamu politikasını izlediği için yeni türden haberdar değildir. AOSP, tedarikçi firma tarafından sağlanan kaynakları bir özellik (ör. hal_foo özelliği) aracılığıyla göstererek bu sorunu çözer. Ancak system/sepolicy/public'te özellik iş ortağı uzantıları desteklenmediğinden bu yöntem tedarikçi firma politikası için kullanılamaz. Erişim, daha önce var olan herkese açık bir tür tarafından sağlanmalıdır.

Örnek: Bir sistem işleminde (AOSP veya AOSP dışı) yapılan bir değişiklik, AOSP dışı yeni tedarikçi bileşeniyle etkileşim şeklini değiştirmelidir.

Sistem resmindeki politika, belirli tedarikçi özelleştirmeleri hakkında bilgi sahibi olmadan yazılmalıdır. Bu nedenle, AOSP'deki belirli arayüzle ilgili politika, tedarikçi politikasının bu özellikleri kullanan gelecekteki sistem politikasını etkinleştirebilmesi için system/sepolicy/public içindeki özellikler aracılığıyla gösterilir. Ancak system/sepolicy/public'teki özellik uzantıları desteklenmez. Bu nedenle, sistem bileşenlerinin yeni tedarikçi bileşenleriyle nasıl etkileşime geçeceğini belirten tüm politikalar (ve AOSP system/sepolicy/public'te mevcut özellikler tarafından ele alınmayan politikalar) device/manufacturer/device-name/sepolicy'te olmalıdır. Bu, sistem türlerinin yalnızca çerçeve OTA'sı kapsamında tedarikçi türlerine izin verilen erişimi değiştiremeyeceği anlamına gelir.