SELinux'u özelleştirme

SELinux işlevselliğinin temel düzeyini entegre ettikten ve sonuçları kapsamlı bir şekilde analiz ettikten sonra, özelleştirmelerinizi Android işletim sistemine dahil etmek için kendi ilke ayarlarınızı ekleyebilirsiniz. Bu politikalar Android Uyumluluk programı gereksinimlerini 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ı ve yönettiği uygulamaları bozma riskiyle karşı karşıya kalırlar. Bu, uyumlu ve çalışır durumda olması için muhtemelen iyileştirilmesi gereken üçüncü taraf uygulamalarını içerir. Uygulamalar, SELinux özellikli cihazlarda çalışmaya devam etmek için herhangi bir değişiklik gerektirmemelidir.

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

• Tüm yeni arka plan programları için SELinux politikası yazın
• Uygun olduğunda önceden tanımlanmış alanları kullanın
• Bir init hizmeti olarak oluşturulan herhangi bir işleme bir etki alanı atayın
• Politika yazmadan önce makrolara aşina olun
• Temel politikadaki değişiklikleri AOSP'ye gönderin

Ve şunu yapmamayı unutmayın:

• Uyumsuz politika oluştur
• Son kullanıcı politikası özelleştirmesine izin ver
• MDM ilke özelleştirmelerine izin ver
• Politika ihlalleriyle kullanıcıları korkut
• Arka kapılar ekle

Belirli 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, verilebilmesi için politikada tüm erişime açıkça izin verilmesi gerektiği anlamına gelir. Android'in varsayılan SELinux politikası zaten Android Açık Kaynak Projesini desteklediğinden, SELinux ayarlarını hiçbir şekilde değiştirmeniz gerekmez. SELinux ayarlarını kişiselleştirirseniz, mevcut uygulamaları bozmamaya büyük özen gösterin. Başlamak:

1. En son Android çekirdeğini kullanın.
2. En az ayrıcalık ilkesini benimseyin.
3. Android'e yalnızca kendi eklemelerinizi ele alın. Varsayılan politika, Android Açık Kaynak Projesi kod tabanıyla otomatik olarak çalışır.
4. Yazılım bileşenlerini tekil görevleri yerine getiren modüller halinde bölümlere ayırın.
5. Bu görevleri ilgisiz işlevlerden izole eden SELinux ilkeleri oluşturun.
6. Bu ilkeleri /device/ manufacturer / device-name /sepolicy dizini içindeki *.te dosyalarına (SELinux ilke kaynak dosyalarının uzantısı) koyun ve bunları yapınıza dahil etmek için BOARD_SEPOLICY değişkenlerini kullanın.
7. Yeni alan adlarını başlangıçta izinli yapın. Bu, etki alanının .te dosyasında izin verilen bir bildirim kullanılarak yapılır.
8. Sonuçları analiz edin ve etki alanı tanımlarınızı iyileştirin.
9. Kullanıcı hata ayıklama yapılarında başka reddetme görünmediğinde izin veren bildirimi kaldırın.

SELinux ilke değişikliğinizi entegre ettikten sonra, SELinux uyumluluğunun ilerlemesini 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ı, gerçek uygulama değil, yalnızca yazılım modeli değiştiğinde değişir.

SELinux'u özelleştirmeye başladığınızda, önce Android'e yaptığınız eklemeleri denetleyin. Yeni bir işlev yürüten bir bileşen eklediyseniz, zorlama modunu açmadan önce bileşenin Android'in güvenlik politikasını ve OEM tarafından hazırlanmış ilişkili tüm ilkeleri karşıladığından emin olun.

Gereksiz sorunları önlemek için, fazla kısıtlayıcı ve uyumsuz olmaktansa aşırı geniş ve aşırı uyumlu olmak daha iyidir, bu da cihaz işlevlerinin bozulmasına neden olur. Tersine, değişiklikleriniz başkalarına fayda sağlayacaksa, değişiklikleri bir yama olarak varsayılan SELinux politikasına göndermelisiniz. Yama, varsayılan güvenlik ilkesine uygulanırsa, her yeni Android sürümünde bu değişikliği yapmanız gerekmez.

Örnek politika beyanları

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

Aşağıdaki örnekte, tüm etki alanlarına /dev/null'dan okuma veya yazma ve /dev/null /dev/zero erişimi verilmiştir.

# 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 };

Bu aynı ifade SELinux *_file_perms makrolarıyla (kısa yol) 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 incelediğimiz DHCP için eksiksiz bir örnek politika:

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 bildirimi, DHCP arka plan programı temel güvenlik ilkesinden ( domain ) miras alır. Önceki ifade örneklerinden, DHCP /dev/null okuyabilir ve öğesine yazabilir.

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

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

net_domain(dhcp) satırında, politika, DHCP'nin TCP paketlerini okuma ve yazma, soketler üzerinden iletişim kurma ve DNS isteklerini yürütme gibi net etki alanından ortak ağ işlevlerini kullanmasına izin verir.

Satırda allow dhcp proc_net:file write; , ilke DHCP'nin /proc içindeki belirli dosyalara yazabileceğini belirtir. Bu satır, SELinux'un ince taneli dosya etiketlemesini gösterir. Yalnızca /proc/sys/net altındaki dosyalara yazma erişimini sınırlamak için proc_net etiketini kullanır.

Örneğin allow dhcp netd:fd use; uygulamaların birbirleriyle etkileşime girmesine nasıl izin verilebileceğini gösterir. Politika, DHCP ve netd'nin dosya tanımlayıcıları, FIFO dosyaları, datagram yuvaları ve UNIX akış yuvaları aracılığıyla birbirleriyle iletişim kurabileceğini söylüyor. DHCP, yalnızca datagram soketlerini ve UNIX akış soketlerini okuyabilir ve bunlardan yazabilir ve bunları oluşturamaz veya açamaz.

Kullanılabilir 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

asla izin verilmeyen kurallar

SELinux asla izin neverallow kuralları, asla gerçekleşmemesi gereken davranışları yasaklar. Uyumluluk testi ile neverallow kuralları artık cihazlar arasında uygulanmaktadır.

Aşağıdaki yönergeler, üreticilerin özelleştirme sırasında asla izin neverallow kurallarla 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 yayına göre değişebilir.

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, diğer süreçler üzerinde büyük ölçüde kontrole izin veren ve yalnızca kuralda özetlenen belirlenmiş sistem bileşenlerine ait olması gereken herhangi bir işlemi ptrace yeteneği verir. Bu yeteneğe duyulan ihtiyaç, genellikle, kullanıcıya yönelik yapılar veya ihtiyaç duyulmayan işlevler için tasarlanmayan bir şeyin 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ın amacı, sistemde rastgele kod yürütülmesini engellemektir. Spesifik olarak, doğrulanmış önyükleme gibi mekanizmalar sayesinde güvenlik garantilerine izin veren yalnızca /system üzerindeki kodun yürütüldüğünü iddia eder. Genellikle, bu neverallow izin verme kuralıyla ilgili bir sorunla karşılaştığınızda en iyi çözüm, sorunlu kodu /system bölümüne taşımaktır.

Android 8.0+ sürümünde SEPolicy'yi özelleştirme

Bu bölüm, Android Açık Kaynak Projesi (AOSP) SEPolicy ve SEPolicy uzantılarıyla ilgili ayrıntılar da dahil olmak üzere, Android 8.0 ve sonraki sürümlerde satıcı SELinux politikası için yönergeler sağlar. SELinux ilkesinin bölümler ve Android sürümleri arasında nasıl uyumlu tutulduğu hakkında daha fazla bilgi için bkz. Uyumluluk .

Politika yerleştirme

Android 7.0 ve önceki sürümlerde, cihaz üreticileri, farklı cihaz türleri arasında AOSP politikasını artırmaya yönelik politika dahil olmak üzere BOARD_SEPOLICY_DIRS öğesine politika ekleyebilir. Android 8.0 ve sonraki sürümlerde, BOARD_SEPOLICY_DIRS bir politika eklemek, politikayı yalnızca satıcı görüntüsüne yerleştirir.

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

• sistem/sepolicy/genel . Satıcıya özel ilkede kullanılmak üzere dışa aktarılan ilkeyi içerir. Her şey Android 8.0 uyumluluk altyapısına giriyor. Genel ilke, özelleştirilmiş ilkenize herhangi bir şeyi /public dahil edebilmeniz için sürümler arasında kalıcılık sağlamak içindir. Bu nedenle, /public içine yerleştirilebilecek politika türü daha kısıtlıdır. Bunu platformun dışa aktarılan politika API'si olarak düşünün: /system ve /vendor arasındaki arabirimle ilgilenen her şey buraya aittir.
• sistem/sepolicy/özel . Sistem görüntüsünün çalışması için gerekli olan ancak satıcı görüntü politikasının bilgisinin olmaması gereken politikayı içerir.
• sistem/sepolicy/satıcı . /vendor içine giren ancak çekirdek platform ağacında bulunan (cihaza özel dizinler değil) bileşenler için politika içerir. Bu, yapı sisteminin cihazlar ve küresel bileşenler arasındaki ayrımının bir eseridir; kavramsal olarak bu, aşağıda açıklanan cihaza özel politikanın bir parçasıdır.
• cihaz/ manufacturer / device-name /sepolicy . Cihaza özel politika içerir. Ayrıca, Android 8.0 ve sonraki sürümlerde satıcı resmindeki bileşenler için ilkeye karşılık gelen ilkeye yönelik cihaz özelleştirmelerini de içerir.

Android 11 ve sonraki sürümlerde system_ext ve ürün bölümleri, bölüme özel ilkeler de içerebilir. system_ext ve ürün ilkeleri de genel ve özel olarak ayrılır ve satıcılar sistem ilkesi gibi system_ext'leri ve ürünün genel ilkelerini kullanabilir.

• SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS . Satıcıya özel ilkede kullanılmak üzere dışa aktarılan ilkeyi içerir. system_ext bölümüne yüklendi.
• SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS . system_ext görüntüsünün çalışması için gerekli olan, ancak satıcı görüntü politikasının bilgisinin olmaması gereken politikayı içerir. system_ext bölümüne yüklendi.
• PRODUCT_PUBLIC_SEPOLICY_DIRS . Satıcıya özel ilkede kullanılmak üzere dışa aktarılan ilkeyi içerir. Ürün bölümüne yüklendi.
• PRODUCT_PRIVATE_SEPOLICY_DIRS . Ürün resminin çalışması için gerekli olan ancak satıcı resmi politikasının bilgisinin olmaması gereken politikayı içerir. Ürün bölümüne yüklendi.

Desteklenen politika senaryoları

Android 8.0 ve sonraki sürümlerle başlatılan cihazlarda, satıcı resmi, OEM sistem görüntüsü ve Google tarafından sağlanan referans AOSP sistem görüntüsü ile çalışmalıdır (ve bu referans görüntüde CTS'yi geçmelidir). Bu gereksinimler, çerçeve ve satıcı kodu arasında temiz bir ayrım sağlar. Bu tür cihazlar aşağıdaki senaryoları destekler.

yalnızca satıcı resmi uzantıları

Örnek : Satıcı görüntüsünden süreçleri destekleyen satıcı görüntüsünden vndservicemanager yeni bir hizmet ekleme.

Önceki Android sürümleriyle başlatılan cihazlarda olduğu gibi, device/ manufacturer / device-name /sepolicy içine cihaza özel özelleştirme ekleyin. Satıcı bileşenlerinin (yalnızca) diğer satıcı bileşenleriyle nasıl etkileşime girdiğini yöneten yeni politika , yalnızca device/ manufacturer / device-name /sepolicy içinde bulunan türleri içermelidir . Burada yazılan ilke, satıcı üzerindeki kodun çalışmasına izin verir, yalnızca çerçeveye yönelik bir OTA'nın parçası olarak güncellenmez ve referans AOSP sistem görüntüsüne sahip bir cihazdaki birleşik ilkede bulunur.

AOSP ile çalışmak için satıcı imajı desteği

Örnek : AOSP tanımlı bir HAL uygulayan yeni bir süreç ekleme (satıcı görüntüsünden hwservicemanager ile kayıtlı).

Önceki Android sürümleriyle başlatılan cihazlarda olduğu gibi, device/ manufacturer / device-name /sepolicy içinde cihaza özel özelleştirme gerçekleştirin. system/sepolicy/public/ 'in bir parçası olarak dışa aktarılan politika kullanıma hazırdır ve satıcı politikasının bir parçası olarak gönderilir. Kamu politikasından türler ve nitelikler, sağlanan asla izin neverallow kısıtlamalara tabi olarak, yeni satıcıya özel bitlerle etkileşimleri belirleyen yeni kurallarda kullanılabilir. Yalnızca satıcıya yönelik durumda olduğu gibi, buradaki yeni ilke, yalnızca çerçeveye yönelik bir OTA'nın parçası olarak güncellenmeyecek ve referans AOSP sistem görüntüsüne sahip bir cihazdaki birleşik ilkede bulunacaktır.

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 ile kayıtlı) ekleme.

Bu politikayı system/sepolicy/private . Bu yeni bitlerin satıcı görüntüsündeki yeni bileşenlerle etkileşime girmesi gerekmemesi koşuluyla, bir ortak sistem görüntüsünde işlevselliği etkinleştirmek için ekstra işlemler veya nesneler ekleyebilirsiniz (özellikle, bu tür işlemler veya nesneler, satıcı görüntüsünden ilke olmadan tam olarak çalışmalıdır) . system/sepolicy/public tarafından dışa aktarılan ilke, yalnızca satıcı görüntüsü uzantıları için olduğu gibi burada da mevcuttur. Bu politika, sistem görüntüsünün bir parçasıdır ve yalnızca çerçeveye yönelik bir OTA'da güncellenebilir, ancak referans AOSP sistem görüntüsü kullanılırken mevcut olmayacaktır.

genişletilmiş AOSP bileşenlerine hizmet eden satıcı resmi uzantıları

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

Sistem ve satıcı arasındaki etkileşim ilkesi, satıcı bölümünde gönderilen device/ manufacturer / device-name /sepolicy dizinine dahil edilmelidir. Bu, referans AOSP görüntüsüyle çalışmak için satıcı görüntüsü desteği eklemeye ilişkin yukarıdaki senaryoya benzer, ancak değiştirilmiş AOSP bileşenlerinin sistem bölümünün geri kalanıyla düzgün bir şekilde çalışması için ek politika gerektirebilmesi dışında (bu, hala sorun olmadığı sürece iyidir). genel AOSP tipi etiketlerine sahiptir).

Genel AOSP bileşenlerinin yalnızca sistem görüntüsü uzantılarıyla etkileşimi için ilke system/sepolicy/private içinde olmalıdır.

yalnızca AOSP arabirimlerine erişen sistem görüntüsü uzantıları

Örnek: Yeni, AOSP olmayan bir sistem işlemi, AOSP'nin dayandığı bir HAL'e erişmelidir.

Bu, yalnızca sistem görüntüsü uzantısı örneğine benzer, ancak yeni sistem bileşenleri system/vendor arabirimi üzerinden etkileşime girebilir. Yeni sistem bileşeninin politikası system/sepolicy/private içinde olmalıdır; bu, AOSP tarafından system/sepolicy/public içinde kurulmuş bir arabirim aracılığıyla olması koşuluyla kabul edilebilirdir (yani, işlevsellik için gereken türler ve nitelikler oradadır). Politika, cihaza özel politikaya dahil edilebilirken, yalnızca çerçeve güncellemesinin bir sonucu olarak diğer system/sepolicy/private türlerini veya değişikliği (politikayı etkileyen herhangi bir şekilde) kullanamaz. Politika, yalnızca çerçeveye yönelik bir OTA'da değiştirilebilir, ancak bir AOSP sistem görüntüsü (yeni sistem bileşenine de sahip olmayacak) kullanılırken mevcut olmayacaktır.

yeni sistem bileşenlerine hizmet eden satıcı-görüntü uzantıları

Örnek: AOSP analoğu olmayan bir istemci işlemi tarafından kullanılmak üzere yeni, AOSP olmayan bir HAL ekleme (ve bu nedenle kendi etki alanını gerektirir).

AOSP uzantıları örneğine benzer şekilde, sistem ve satıcı arasındaki etkileşimler için ilke, satıcı bölümünde sevk edilen device/ manufacturer / device-name /sepolicy dizinine girmelidir (sistem ilkesinin satıcıya özel ayrıntılar hakkında hiçbir bilgisinin olmamasını sağlamak için). system/sepolicy/public içinde genişleten yeni genel türleri ekleyebilirsiniz; bu sadece mevcut AOSP politikasına ek olarak yapılmalıdır, yani AOSP kamu politikasını kaldırmayın. Yeni genel türler daha sonra system/sepolicy/private ve device/ manufacturer / device-name /sepolicy içinde ilke için kullanılabilir.

system/sepolicy/public yapılan her eklemenin, bir eşleme dosyasında izlenmesi gereken ve diğer kısıtlamalara tabi olan yeni bir uyumluluk garantisi sunarak karmaşıklık eklediğini unutmayın. system/sepolicy/public içinde yalnızca yeni türler ve ilgili izin verme kuralları eklenebilir; öznitelikler ve diğer ilke ifadeleri desteklenmez. Ayrıca, /vendor ilkesindeki nesneleri doğrudan etiketlemek için yeni genel türler kullanılamaz.

Desteklenmeyen politika senaryoları

Android 8.0 ve sonraki sürümlerle başlatılan cihazlar, aşağıdaki politika senaryosunu ve örnekleri desteklemez.

Yalnızca çerçeve OTA'sından sonra yeni satıcı görüntüsü bileşenlerine izin verilmesi gereken sistem görüntüsüne ek uzantılar

Örnek: Kendi etki alanına ihtiyaç duyan yeni bir AOSP dışı sistem işlemi, sonraki Android sürümüne eklenir ve AOSP olmayan yeni bir HAL'e erişmesi gerekir.

Yeni sistem türünün yalnızca çerçeve OTA'sında tanıtılması dışında, yeni (AOSP olmayan) sistem ve satıcı bileşenleri etkileşimine benzer. Yeni tür, system/sepolicy/public içindeki politikaya eklenebilse de, yalnızca Android 8.0 sistem genel politikasını izlediği için mevcut satıcı politikasının yeni tür hakkında bilgisi yoktur. AOSP bunu, bir öznitelik (örneğin hal_foo özniteliği) aracılığıyla satıcı tarafından sağlanan kaynakları açığa çıkararak gerçekleştirir, ancak öznitelik ortağı uzantıları system/sepolicy/public içinde desteklenmediğinden, bu yöntem satıcı politikası için kullanılamaz. Erişim, önceden var olan bir genel tür tarafından sağlanmalıdır.

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

Sistem görüntüsündeki ilke, belirli satıcı özelleştirmeleri bilgisi olmadan yazılmalıdır. AOSP'deki belirli arayüzlerle ilgili politika, sistem/sepolicy/public içindeki öznitelikler aracılığıyla ifşa edilir, böylece satıcı politikası, bu öznitelikleri kullanan gelecekteki sistem politikasını seçebilir. Ancak, system/sepolicy/public içindeki öznitelik uzantıları desteklenmez , bu nedenle sistem bileşenlerinin yeni satıcı bileşenleriyle (ve AOSP system/sepolicy/public içinde zaten mevcut olan öznitelikler tarafından işlenmeyen) nasıl etkileşime girdiğini belirleyen tüm politikalar device/ manufacturer / device-name /sepolicy 'da olmalıdır. device/ manufacturer / device-name /sepolicy . Bu, sistem türlerinin, yalnızca çerçeveye yönelik bir OTA'nın parçası olarak satıcı türlerine izin verilen erişimi değiştiremeyeceği anlamına gelir.