Bu sayfa, Cloud Translation API ile çevrilmiştir.

SELinux'u özelleştirme

SELinux işlevlerinin temel düzeyini entegre ettikten ve sonuçları ayrıntılı olarak analiz ettikten sonra, Android işletim sistemindeki özelleştirmelerinizi kapsayacak 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ın ve yönettiği uygulamaların bozulma riski vardır. Politikalara uygun 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 sürece alan adı atama
Politika yazmadan önce makroları öğrenin
Temel politikadaki değişiklikleri AOSP'ye gönderme

Şunları yapmamaya dikkat edin:

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

Belirli gereksinimler için Android Uyumluluk Tanımı dokümanının Ç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 Open Source Project'i desteklediğinden SELinux ayarlarını herhangi bir şekilde değiştirmeniz gerekmez. SELinux ayarlarını özelleştiriyorsanız mevcut uygulamaları bozmamaya çok dikkat edin. Başlamak için:

En son Android çekirdeğini kullanın.
En az ayrıcalık ilkesini benimseyin.
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.
Yazılım bileşenlerini tek bir görevi yerine getiren modüllere ayırın.
Bu görevleri alakasız işlevlerden ayıran SELinux politikaları oluşturun.
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.
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.
Sonuçları analiz edin ve alan tanımlarınızı hassaslaştırın.
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ğundan emin olmak 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şlarken önce Android'e eklediğiniz öğeleri denetleyin. Yeni bir işlev yürüten bir bileşen eklediyseniz modu zorunlu kılmadan önce bileşenin, Android'in güvenlik politikasının yanı sıra OEM tarafından oluşturulan ilişkili tüm 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. Öte yandan, değişiklikleriniz başkaları için yararlı olacaksa değişiklikleri varsayılan SELinux politikasına 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 ifadeleri

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 yazılabilir (kısaca):

# 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 verilen 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, politika DHCP'nin /proc içindeki belirli dosyalara yazabileceğini belirtir. 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ırlamak 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

Sınıf	İzin
dosya	ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton
dizin	add_name remove_name reparent search rmdir open audit_access execmod
yuva	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
işlem	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
özellik	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 FAZLA	VE DAHA FAZLASI

neverallow kuralları

SELinux neverallow kuralları, hiçbir zaman gerçekleşmemesi gereken davranışları yasaklar. Uyumluluk testiyle SELinux neverallow kuralları artık cihazlar arasında zorunlu kılınmaktadır.

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 özelliği, diğer işlemler üzerinde büyük ölçüde kontrol imkanı sağlayan ve yalnızca kuralda belirtilen belirlenmiş sistem bileşenlerine ait olan herhangi bir işlemi ptrace yapma olanağı tanır. Bu özelliğin gerekliliği genellikle kullanıcılara yönelik derlemeler için tasarlanmamış bir öğenin 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. Genellikle, bu neverallow kuralıyla ilgili bir sorunla karşılaştığınızda 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'yi özelleştirme

Bu bölümde, Android 8.0 ve sonraki sürümlerde tedarikçi SELinux politikası ile ilgili yönergeler (Android Açık Kaynak Projesi (AOSP) SEPolicy ve SEPolicy uzantılarıyla ilgili ayrıntılar dahil) 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, sürümler genelinde kalıcı olduğu için özelleştirilmiş politikanıza /public ile ilgili her şeyi dahil edebilirsiniz. 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 olarak değiştirin. 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 giren ancak temel platform ağacında bulunan (cihaza özgü dizinlerde değil) bileşenlerin politikasını 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. Ayrıca, Android 8.0 ve sonraki sürümlerde tedarikçi firma görüntüsündeki bileşenlere ilişkin politikaya karşılık gelen politikada yapılan cihaz özelleştirmelerini de içerir.

Android 11 ve sonraki sürümlerde system_ext ve ürün bölümleri, bölüme özgü 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üklendi.
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.

Not: GSI kullanıldığında, OEM'nin system_ext ile ürün bölümleri eklenmez. OEM'ye özgü tür tanımları eksik olduğu için tedarikçi sepolicy'sinde OEM'nin system_ext ve ürün herkese açık politikasını kullanan kurallar NOP olur.

Not: system_ext ve ürün herkese açık politikalarını kullanırken çok dikkatli olun. Herkese açık politikalar, system_ext/product ile tedarikçi firma arasında dışa aktarılan API işlevi görür. İş ortaklarının uyumluluk sorunlarını kendilerinin yönetmesi gerekir.

Desteklenen politika senaryoları

Android 8.0 ve sonraki sürümlerin yüklü olduğu cihazlarda, tedarikçi firma görüntüsünün Google tarafından sağlanan OEM sistem görüntüsü ve referans AOSP sistem görüntüsüyle uyumlu olması (ve bu referans görüntüde CTS'yi iletmesi) gerekir. 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ünden işlemleri destekleyen yeni bir hizmet ekleme.

Önceki Android sürümleriyle kullanıma sunulan cihazlarda olduğu gibi, device/manufacturer/device-name/sepolicy'e 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 vendor-image 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. Bu yeni bitlerin tedarikçi görüntüsündeki yeni bileşenlerle etkileşim kurmasına gerek olmadığı sürece (özellikle de bu tür işlemler veya nesneler tedarikçi görüntüsü tarafından alınan politika olmadan tam olarak çalışmalıdır) iş ortağı sistem görüntüsünde işlevselliği etkinleştirmek için fazladan işlemler veya nesneler ekleyebilirsiniz. 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 ve tedarikçi arasındaki etkileşim politikası, tedarikçi firma bölümünde gönderilen device/manufacturer/device-name/sepolicy dizinine eklenmelidir. Bu, referans AOSP görüntüsüyle çalışmak için tedarikçi firma görüntü desteği ekleme senaryosuna 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 içinde 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 özel politika kapsamına dahil edilebilse de yalnızca çerçeve güncellemesi sonucunda diğer system/sepolicy/private türlerini kullanamaz veya politikaları etkileyen herhangi bir değişiklik yapamaz. 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 uzantıları örneğine benzer şekilde, sistem ve tedarikçi firma arasındaki etkileşimlere yönelik politika, tedarikçi firma bölümünde gönderilen device/manufacturer/device-name/sepolicy dizinine dahil edilmelidir (sistem politikasının tedarikçi firmaya ö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 yapılan her eklemenin, bir eşleme dosyasında izlenmesi gereken ve başka kısıtlamalara tabi olan yeni bir uyumluluk garantisini ortaya çıkararak 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ümlerle kullanıma sunulan cihazlar aşağıdaki politika senaryosunu ve örneklerini desteklemez.

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 yönelik 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 ürününde politikaya eklenebilir ancak yalnızca Android 8.0 sisteminin genel politikasını izlediği için mevcut tedarikçi firma politikası yeni tür hakkında bilgiye sahip 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 giderir. 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, bu işlemin AOSP dışı yeni tedarikçi bileşeniyle etkileşim şeklini değiştirmelidir.

Sistem görüntüsünde bulunan 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 işlenmeyenler) 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.