Google, Siyah topluluklar için ırksal eşitliği ilerletmeye kararlıdır. Nasıl olduğunu gör.
Bu sayfa, Cloud Translation API ile çevrilmiştir.
Switch to English

SELinux'u Özelleştirme

SELinux işlevselliğinin temel seviyesini entegre ettikten ve sonuçları kapsamlı bir şekilde analiz ettikten sonra, özelleştirmelerinizi Android işletim sistemine dahil etmek için kendi politika ayarlarınızı ekleyebilirsiniz. Bu politikalar yine de 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 riski taşırlar. Bu, uyumlu ve operasyonel olması için geliştirilmesi gereken üçüncü taraf uygulamaları da içerir. Uygulamalar, SELinux özellikli cihazlarda çalışmaya devam etmek için herhangi bir değişiklik gerektirmemelidir.

SELinux'u özelleştirmeye başlarken aşağıdakileri unutmayın:

  • Tüm yeni cinler için SELinux politikası yaz
  • Uygun olduğunda önceden tanımlanmış alan adlarını kullanın
  • init hizmeti olarak oluşturulan işlemlere etki alanı atayın
  • Politika yazmadan önce makroları tanıyın
  • Temel politikadaki değişiklikleri AOSP'ye gönderme

Ve şunları yapmamaya dikkat edin:

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

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

SELinux bir beyaz liste yaklaşımı kullanır, yani politikaya erişim için tüm erişime açıkça izin verilmelidir. Android'in varsayılan SELinux politikası zaten Android Açık Kaynak Projesi'ni desteklediğinden, SELinux ayarlarını hiçbir şekilde değiştirmeniz gerekmez. SELinux ayarlarını özelleştirirseniz, mevcut uygulamaları kırmamaya ö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 eklemelerinize hitap edin. Varsayılan ilke, Android Açık Kaynak Projesi kod tabanıyla otomatik olarak çalışır.
  4. Yazılım bileşenlerini tekil görevleri yürüten modüllere ayırın.
  5. Bu görevleri ilgisiz işlevlerden ayıran SELinux ilkeleri oluşturun.
  6. Bu ilkeleri /device/ manufacturer / device-name /sepolicy dizinindeki *.te dosyalarına (SELinux ilke kaynak dosyaları uzantısı) yerleştirin ve bunları BOARD_SEPOLICY dahil etmek için BOARD_SEPOLICY değişkenlerini kullanın.
  7. Başlangıçta yeni alan adlarına izin verin. Bu, etki alanının .te dosyasında izin veren bir bildirim 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 bir reddetme görüntülenmediğinde izin veren bildirimi kaldırın.

SELinux politika 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ı sadece gerçek uygulama değil, yazılım modeli değiştiğinde değişir.

SELinux'u özelleştirmeye başladığınızda, önce Android'e eklemelerinizi 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ın yanı sıra OEM tarafından hazırlanmış tüm ilgili politikaları karşıladığından emin olun.

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

Örnek politika bildirimleri

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

Aşağıdaki örnekte, tüm etki alanlarından veya yazma okuma erişimine sahip tüm /dev/null ve okuma /dev/zero .

# 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ı (kısayol) ile de 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 aşağıda 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 bildirimi olan DHCP arka plan programı temel güvenlik ilkesinden ( domain ) devralınır. Önceki ifade örneklerinden DHCP, /dev/null okuyabilir ve bu /dev/null yazabilir.

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

In init_daemon_domain(dhcp) hattı, politika DHCP den kökenli devletler init ve onunla iletişim kurmaya izin verilir.

net_domain(dhcp) satırında, ilke DHCP'nin TCP paketlerini okuma ve yazma, soketler üzerinden iletişim kurma ve DNS istekleri yürütme gibi net etki alanındaki 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.

allow dhcp netd:fd use; ile başlayan örneğin son bloğu allow dhcp netd:fd use; uygulamaların birbirleriyle nasıl etkileşime girmesine izin verilebileceğini gösterir. Politika, DHCP ve ağın dosya tanımlayıcıları, FIFO dosyaları, datagram soketleri ve UNIX akış soketleri 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.

Mevcut kontroller

Sınıf izin
dosya
ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton
rehber
add_name remove_name reparent search rmdir open audit_access execmod
priz
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
dosya sistemi
mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget
süreç
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
güvenlik
compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy
kabiliyet
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

DAHA

VE DAHASI

neverallow kuralları

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

Aşağıdaki yönergeler için, ilgili yardım üreticileri önlemek hataları amaçlanan neverallow özelleştirme sırasında kurallara. Burada kullanılan kural numaraları Android 5.1'e karşılık gelir ve sürümle değişebilir.

Kural 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
İçin man sayfasına bakın ptrace . sys_ptrace yeteneği yeteneği verir ptrace diğer süreçler üzerinde kontrol büyük bir verir ve kural ana hatlarıyla belirlenmiş sistem bileşenlerine sadece ait olmalıdır herhangi bir işlem. Bu özelliğe duyulan ihtiyaç, genellikle kullanıcılara yönelik yapılar veya gerekli olmayan işlevler için amaçlanmayan bir şeyin varlığını gösterir. Gereksiz bileşeni çıkarın.

Kural 76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
Bu kural, sistemde rasgele kod yürütülmesini önlemeyi amaçlamaktadır. Özellikle, 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 kuralında bir sorunla karşılaşıldığında en iyi çözüm, rahatsız edici kodu /system bölümüne taşımaktır.

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

Bu bölüm, Android Açık Kaynak Projesi (AOSP) SEPolicy ve SEPolicy uzantılarıyla ilgili ayrıntılar 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ümlerinde nasıl uyumlu tutulduğu hakkında daha fazla bilgi için bkz. Uyumluluk .

Politika yerleştirme

Android 7.0 ve önceki sürümlerinde, cihaz üreticileri, farklı cihaz türlerinde AOSP politikasını güçlendirmeyi amaçlayan politika da dahil olmak üzere BOARD_SEPOLICY_DIRS politika ekleyebilir. Android 8.0 ve sonraki sürümlerde, BOARD_SEPOLICY_DIRS bir ilke eklemek, ilkeyi 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:

  • sistemi / sepolicy / public . Satıcıya özgü politikada kullanılmak üzere dışa aktarılan politikayı içerir. Her şey Android 8.0 uyumluluk altyapısına giriyor. Kamu politikası, yayınlanmış sürümlerde kalmaya yöneliktir, böylece özelleştirilmiş politikanıza herhangi bir şeyi /public dahil edebilirsiniz. Bu nedenle /public getirilebilecek politika türü daha kısıtlıdır. Bunu platformun dışa aktarılan politika API'sini düşünün: /system ve /vendor arasındaki arayüzle ilgili her şey buraya aittir.
  • sistemi / sepolicy / private . Sistem görüntüsünün çalışması için gerekli olan ancak satıcı imaj politikasının hiçbir bilgisi olmaması gereken politikayı içerir.
  • sistemi / sepolicy / satıcı . İçeri /vendor giren, ancak çekirdek platform ağacında bulunan (cihaza özgü dizinler değil) bileşenler için politika içerir. Bu, yapı sisteminin cihazlar ve global bileşenler arasındaki ayrımının bir ürünüdür; kavramsal olarak bu, aşağıda açıklanan cihaza özgü 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 tedarikçi resmindeki bileşenler için politikaya karşılık gelen politikaya ilişkin cihaz özelleştirmelerini de içerir.

Desteklenen politika senaryoları

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

salt satıcı-resim uzantıları

Örnek : vndservicemanager satıcı imajından süreçleri destekleyen satıcı imajından yeni bir servis ekleme.

Önceki Android sürümleriyle başlatılan cihazlarda olduğu gibi, device/ manufacturer / device-name /sepolicy özel özelleştirme ekleyin. Satıcı bileşenlerinin (yalnızca) diğer satıcı bileşenleriyle nasıl etkileşime girdiğini düzenleyen yeni politika , yalnızca device/ manufacturer / device-name /sepolicy . Burada yazılan politika, satıcının kodunun çalışmasına izin verir, yalnızca çerçeve OTA'nın bir parçası olarak güncellenmez ve referans AOSP sistem görüntüsüne sahip bir cihazda birleştirilmiş politikada bulunur.

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

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

Önceki Android sürümleriyle başlatılan cihazlarda olduğu gibi, device/ manufacturer / device-name /sepolicy özel özelleştirme device/ manufacturer / device-name /sepolicy . system/sepolicy/public/ 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 öznitelikler, tedarikçiye özgü bitlerle sağlanan etkileşimleri belirleyen yeni kurallarda kullanılabilir ve sağlanan neverallow kısıtlamalarına tabidir. Yalnızca satıcı durumunda olduğu gibi, buradaki yeni politika yalnızca çerçeve OTA'nın bir parçası olarak güncellenmeyecek ve referans AOSP sistem görüntüsüne sahip bir cihazda birleştirilmiş politikada yer alacaktır.

salt sistem resmi uzantıları

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

Bu politikayı system/sepolicy/private . İş ortağı sistem görüntüsünde işlevselliği etkinleştirmek için fazladan işlemler veya nesneler ekleyebilirsiniz, ancak bu yeni bitlerin satıcı görüntüsünde yeni bileşenlerle etkileşime girmesi gerekmiyorsa (özellikle, bu tür işlemlerin veya nesnelerin satıcı görüntüsünün ilkesi olmadan tam olarak çalışması gerekir) . system/sepolicy/public tarafından dışa aktarılan politika, tıpkı yalnızca satıcıya ait resim 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çeve OTA'da güncellenebilir, ancak referans AOSP sistem görüntüsü kullanılırken mevcut olmayacaktır.

genişletilmiş AOSP bileşenleri sunan satıcı resmi uzantıları

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

Sistem ve satıcı arasındaki etkileşim politikası, satıcı bölümünde gönderilen device/ manufacturer / device-name /sepolicy dizinine dahil edilmelidir. Bu, değiştirilen AOSP bileşenlerinin sistem bölümünün geri kalanıyla düzgün şekilde çalışması için ek ilke gerektirebilmesi dışında yukarıdaki AOSP resmiyle çalışmak için tedarikçi resmi desteği ekleme senaryosuna benzer (yine de devam ettikleri sürece iyidir) herkese açık AOSP türü etiketlere sahip).

Genel AOSP bileşenlerinin yalnızca sistem görüntüsü içeren uzantılarla etkileşimi için politika, 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'ye erişmelidir.

system/vendor arabiriminde yeni sistem bileşenleri etkileşimde bulunabilmesi dışında, bu durum yalnızca sistem resmi uzantı örneğine benzer. Yeni sistem bileşeni için politika, system/sepolicy/private AOSP tarafından önceden kurulmuş bir arabirim (yani işlevsellik için gerekli olan türler ve öznitelikler system/sepolicy/public aracılığıyla kabul system/sepolicy/private , system/sepolicy/private system/sepolicy/public . İlke aygıta özgü ilkeye dahil edilebilirken, yalnızca çerçeveye özgü bir güncellemenin sonucu olarak diğer system/sepolicy/private türleri system/sepolicy/private veya (ilkeyi etkileyen herhangi bir şekilde) değişiklik yapamaz. Politika yalnızca çerçeve OTA'da değiştirilebilir, ancak bir AOSP sistem görüntüsü (yeni sistem bileşenine sahip olmayacak) kullanılırken mevcut olmayacaktır.

yeni sistem bileşenleri sunan satıcı resmi uzantıları

Örnek: AOSP analogu olmadan bir istemci işlemi tarafından kullanılmak üzere yeni bir AOSP olmayan 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 gönderilen device/ manufacturer / device-name /sepolicy dizinine device/ manufacturer / device-name /sepolicy (sistem ilkesinin satıcıya özgü ayrıntılar hakkında hiçbir bilgi sahibi olmamasını sağlamak için). Politikayı genişleten system/sepolicy/public 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 politika için kullanılabilir.

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

Desteklenmeyen politika senaryoları

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

Yalnızca çerçeve OTA'dan sonra yeni tedarikçi resmi bileşenlerine izin verilmesi gereken sistem resmi ek uzantıları

Örnek: Bir sonraki Android sürümüne kendi etki alanını gerektiren yeni bir AOSP olmayan sistem işlemi eklenir ve yeni, AOSP olmayan bir HAL'a erişmesi gerekir.

Yeni (AOSP olmayan) sistem ve satıcı bileşenleri etkileşimine benzer, ancak yeni sistem türü yalnızca çerçeve OTA'da tanıtılır. Yeni tür system/sepolicy/public ilkesine eklenebilse de, mevcut satıcı ilkesinin yalnızca Android 8.0 sistem genel ilkesini izlediği için yeni tür hakkında bilgisi yoktur. AOSP bunu satıcı tarafından sağlanan kaynakları bir öznitelik (örn. hal_foo özniteliği) aracılığıyla hal_foo ancak öznitelik ortağı uzantıları system/sepolicy/public desteklenmediğinden, bu yöntem satıcı ilkesi tarafından 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şimini değiştirmelidir.

Sistem görüntüsü üzerindeki politika, belirli satıcı özelleştirmeleri hakkında bilgi sahibi olmadan yazılmalıdır. AOSP'deki belirli arayüzlere ilişkin politika, böylece sistem / sepolicy / public sistemindeki nitelikler aracılığıyla ortaya çıkar, böylece satıcı politikası bu nitelikleri kullanan gelecekteki sistem politikasını tercih edebilir. Ancak, system/sepolicy/public içindeki özellik uzantıları desteklenmez , bu nedenle sistem bileşenlerinin yeni satıcı bileşenleri ile nasıl etkileşimde bulunduğunu belirleyen (ve AOSP system/sepolicy/public zaten mevcut olan özellikler tarafından system/sepolicy/public ) tüm politikaların device/ manufacturer / device-name /sepolicy . Bu, sistem türlerinin, yalnızca çerçeve OTA'nın bir parçası olarak satıcı türlerine izin verilen erişimi değiştiremeyeceği anlamına gelir.