SELinux'u özelleştirme

SELinux işlevselliğinin temel düzeyini entegre ettikten ve sonuçları kapsamlı bir şekilde analiz ettikten sonra, özelleştirmelerinizi kapsayacak şekilde Android işletim sistemine 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 riskiyle karşı karşıya kalırsınız. Buna uyumlu ve çalışır durumda olması için muhtemelen iyileştirilmesi gereken üçüncü taraf uygulamaları da dahildir. Uygulamaların SELinux özellikli cihazlarda çalışmaya devam etmesi için hiçbir değişiklik gerektirmemesi gerekir.

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

  • Tüm yeni arka plan programları için SELinux politikasını yazın
  • Uygun olduğunda önceden tanımlanmış alanları kullanın
  • 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ının özelleştirilmesine izin ver
  • MDM ilkesi özelleştirmelerine izin ver
  • Kullanıcıları politika ihlalleriyle korkutmak
  • Arka kapı ekle

Özel 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şimlere izin 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 Projesini desteklediğinden, SELinux ayarlarını hiçbir şekilde değiştirmeniz gerekmez. SELinux ayarlarını kişiselleştirirseniz mevcut uygulamaları bozmamaya çok dikkat edin. 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 yapı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 yürüten modüller halinde bölümlere ayırın.
  5. Bu görevleri ilgisiz işlevlerden ayıran SELinux ilkeleri oluşturun.
  6. Bu politikaları /device/ manufacturer / device-name /sepolicy dizinindeki *.te dosyalarına (SELinux politika kaynak dosyalarının uzantısı) koyun ve bunları yapınıza dahil etmek için BOARD_SEPOLICY değişkenlerini kullanın.
  7. Başlangıçta yeni alan adlarını izin verilebilir hale getirin. Bu, alan adının .te dosyasındaki izin verici bir bildirim kullanılarak yapılır.
  8. Sonuçları analiz edin ve alan tanımlarınızı hassaslaştırın.
  9. Kullanıcı hata ayıklama yapılarında başka reddetme görülmediğinde izin verici bildirimini kaldırın.

SELinux politikası değişikliğinizi entegre ettikten sonra, SELinux uyumluluğunun ileriye dönük olmasını 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ı, fiili uygulama değil, yalnızca yazılım modeli değiştiğinde değişir.

SELinux'u özelleştirmeye başladığınızda öncelikle Android'e yaptığınız eklemeleri denetleyin. Yeni bir işlevi 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 oluşturulan ilgili politikalara da uyduğundan emin olun.

Gereksiz sorunları önlemek için, aşırı kısıtlayıcı ve uyumsuz olmaktansa, aşırı geniş ve aşırı uyumlu olmak, cihaz işlevlerinin bozulmasına yol açmaktan daha iyidir. Bunun tersine, eğer değişiklikleriniz başkalarına fayda sağlayacaksa, değişiklikleri varsayılan SELinux politikasına bir yama olarak göndermelisiniz. Düzeltme eki varsayılan güvenlik politikasına uygulanırsa bu değişikliği her yeni Android sürümünde yapmanıza gerek kalmayacaktır.

Örnek politika bildirimleri

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

Aşağıdaki örnekte, tüm etki alanlarına /dev/null okuma veya yazma ve /dev/zero okuma 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 };

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 politikasının tam bir örneğini burada bulabilirsiniz:

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 politikasından ( domain ) miras alır. Önceki ifade örneklerinde görüldüğü gibi, DHCP /dev/null okuyabilir ve ona yazabilir.

İkinci satırda DHCP, izin veren bir 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; politika, DHCP'nin /proc içindeki belirli dosyalara yazabileceğini belirtir. Bu satır SELinux'un ince taneli dosya etiketlemesini göstermektedir. Yazma erişimini yalnızca /proc/sys/net altındaki dosyalara 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 birbirleriyle nasıl etkileşime girmesine izin verilebileceğini gösterir. Politika, DHCP ve netd'nin birbirleriyle dosya tanımlayıcıları, FIFO dosyaları, datagram soketleri ve UNIX akış soketleri aracılığıyla iletişim kurabileceğini söylüyor. DHCP yalnızca datagram yuvalarına ve UNIX akış yuvalarına okuma ve yazma yapabilir; bunları oluşturamaz veya açamaz.

Mevcut 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
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
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
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

kurallara asla izin verme

SELinux neverallow kuralları asla gerçekleşmemesi gereken davranışları yasaklar. Uyumluluk testiyle SELinux neverallow kuralları artık cihazlar arasında uygulanıyor.

Aşağıdaki yönergeler, ü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ş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 belirtilen belirlenmiş sistem bileşenlerine ait olması gereken herhangi bir süreci ptrace yeteneği verir. Bu yeteneğe duyulan ihtiyaç çoğu zaman, kullanıcıya yönelik yapılara veya ihtiyaç duyulmayan işlevlere yönelik olmayan 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ı sistem üzerinde rastgele kod çalıştırılmasını 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ü ileri sürer. 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+'da SEPolicy'yi özelleştirme

Bu bölüm, Android Açık Kaynak Projesi (AOSP) SEPolicy ve SEPolicy uzantılarına ilişkin ayrıntılar da dahil olmak üzere Android 8.0 ve sonraki sürümlerde satıcının SELinux politikasına ilişkin 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şimi

Android 7.0 ve önceki sürümlerde, cihaz üreticileri BOARD_SEPOLICY_DIRS , farklı cihaz türlerinde AOSP politikasını artırmaya yönelik politika da dahil olmak üzere 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/public . Satıcıya özel politikada kullanılmak üzere dışa aktarılan politikayı içerir. Her şey Android 8.0 uyumluluk altyapısına giriyor. Kamu politikasının sürümler boyunca kalıcı olması amaçlanmıştır, böylece özelleştirilmiş politikanıza /public herhangi bir şeyi dahil edebilirsiniz. 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 arayüzle 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 bilgi sahibi olmaması gereken politikayı içerir.
  • sistem/sepolicy/satıcı . /vendor dizinine giren ancak çekirdek platform ağacında (cihaza özgü dizinlerde değil) bulunan bileşenlere yönelik politikayı içerir. Bu, yapı sisteminin cihazlar ve küresel 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 politikayı içerir. Ayrıca, Android 8.0 ve sonraki sürümlerde satıcı görüntüsündeki bileşenlere ilişkin politikaya karşılık gelen politikaya 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 özgü politikalar da içerebilir. system_ext ve ürün politikaları da genel ve özel olarak bölünmüştür ve satıcılar, sistem politikası gibi system_ext'in ve ürünün genel politikalarını kullanabilir.

  • SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS . Satıcıya özel politikada kullanılmak üzere dışa aktarılan politikayı içerir. System_ext bölümüne kuruldu.
  • 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 bu konuda bilgi sahibi olmaması gereken politikayı içerir. System_ext bölümüne kuruldu.
  • PRODUCT_PUBLIC_SEPOLICY_DIRS . Satıcıya özel 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 görselinin işleyişi için gerekli olan ancak satıcı imaj politikasının bu konuda bilgi sahibi olmaması gereken politikayı içerir. Ürün bölümüne yüklendi.
Not: GSI kullanıldığında OEM'in system_ext ve ürün bölümleri bağlanmayacaktır. OEM'in system_ext ve ürün genel ilkesini kullanan satıcı politikasındaki kurallar, OEM'e özgü tür tanımları eksik olduğundan NOP olur.
Not: system_ext ve ürün genel politikalarını kullanırken daha dikkatli olun. Genel politikalar, system_ext/product ile satıcı arasında dışa aktarılan API görevi görür. İş ortaklarının uyumluluk sorunlarını kendilerinin yönetmesi gerekir.

Desteklenen politika senaryoları

Android 8.0 ve sonraki sürümlerle başlatılan cihazlarda satıcı 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üyle çalışması (ve bu referans görüntüsünde CTS'yi iletmesi) gerekir. Bu gereksinimler, çerçeve ile satıcı kodu arasında temiz bir ayrım yapılmasını sağlar. Bu tür cihazlar aşağıdaki senaryoları destekler.

yalnızca satıcı görseli uzantıları

Örnek : Satıcı görüntüsündeki işlemleri 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 cihaza ö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 bulunan türleri içermelidir . Burada yazılan politika, satıcı kodunun çalışmasına izin verir, yalnızca çerçeve OTA'nın parçası olarak güncellenmeyecek ve referans AOSP sistem görüntüsüne sahip bir cihazdaki birleşik politikada mevcut olacaktır.

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

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

Önceki Android sürümleriyle başlatılan cihazlarda olduğu gibi, device/ manufacturer / device-name /sepolicy bölümünde 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ındaki türler ve nitelikler, sağlanan neverallow kısıtlamalara tabi olarak, satıcıya özgü yeni bitlerle etkileşimleri belirleyen yeni kurallarda kullanılabilir. Yalnızca satıcı durumunda olduğu gibi, buradaki yeni politika, yalnızca çerçeve OTA'nın parçası olarak güncellenmeyecek ve referans AOSP sistem görüntüsüne sahip bir cihazdaki birleşik politikada mevcut olacaktır.

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

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

Bu politikayı system/sepolicy/private ekleyin. Bu yeni bitlerin satıcı görüntüsündeki yeni bileşenlerle etkileşime girmesine gerek olmaması 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 politika olmadan tam olarak çalışmalıdır) . system/sepolicy/public tarafından dışa aktarılan politika, yalnızca satıcı görseli uzantılarında 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'sında güncellenebilir ancak referans AOSP sistem görüntüsü kullanıldığında mevcut olmayacaktır.

genişletilmiş AOSP bileşenlerine hizmet eden satıcı görseli uzantıları

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

Sistem ile satıcı arasındaki etkileşime ilişkin politika, 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 üzere satıcı görüntüsü desteğinin eklenmesine ilişkin yukarıdaki senaryoya benzer; ancak değiştirilmiş AOSP bileşenleri, sistem bölümünün geri kalanıyla düzgün bir şekilde çalışmak için ek politika gerektirebilir (bu, hala mevcut oldukları sürece sorun değildir). genel AOSP türü etiketlerine sahip olun).

Genel AOSP bileşenlerinin salt sistem görüntüsü uzantılarıyla etkileşimine ilişkin politika system/sepolicy/private içinde olmalıdır.

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

Örnek: AOSP olmayan yeni bir sistem işleminin, AOSP'nin dayandığı bir HAL'a erişmesi gerekir.

Bu , yalnızca sistem görüntüsü uzantısı örneğine benzer, ancak yeni sistem bileşenleri system/vendor arayüzünde etkileşime girebilir. Yeni sistem bileşenine ilişkin politika, system/sepolicy/private dosyasına girmelidir; bu, AOSP tarafından halihazırda system/sepolicy/public dosyasında oluşturulmuş bir arayüz aracılığıyla olması koşuluyla kabul edilebilir (yani işlevsellik için gereken türler ve nitelikler oradadır). Politika, cihaza özel politikaya dahil edilebilse de, yalnızca çerçeve güncellemesinin bir sonucu olarak diğer system/sepolicy/private türlerini kullanamaz veya değişiklik (politikayı etkileyecek herhangi bir şekilde) yapamaz. Politika, yalnızca çerçeve OTA'sında değiştirilebilir, ancak bir AOSP sistem görüntüsü kullanıldığında mevcut olmayacaktır (bu da yeni sistem bileşenine sahip olmayacaktır).

yeni sistem bileşenlerine hizmet eden satıcı görseli uzantıları

Örnek: AOSP benzeri olmayan bir istemci işlemi tarafından kullanılmak üzere AOSP olmayan yeni bir HAL eklemek (ve dolayısıyla kendi etki alanını gerektirir).

AOSP uzantıları örneğine benzer şekilde, sistem ve satıcı arasındaki etkileşimlere ilişkin politika, satıcı bölümünde gönderilen device/ manufacturer / device-name /sepolicy dizinine girmelidir (sistem politikasının satıcıya özgü ayrıntılar hakkında bilgi sahibi olmadığından emin olmak için). system/sepolicy/public dosyasında politikayı genişleten yeni genel türler ekleyebilirsiniz; bu yalnızca 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çindeki politika için kullanılabilir.

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

Desteklenmeyen politika senaryoları

Android 8.0 ve üzeri 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 yönelik ek uzantılar

Örnek: Bir sonraki Android sürümüne, kendi etki alanını gerektiren, AOSP olmayan yeni bir sistem işlemi eklenir ve yeni, AOSP olmayan bir HAL'ye 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 dosyasındaki politikaya eklenebilse de, mevcut satıcı politikası yalnızca Android 8.0 sistem genel politikasını izlediğinden yeni tür hakkında hiçbir bilgiye sahip değildir. AOSP bunu, satıcı tarafından sağlanan kaynakları bir öznitelik (örn. hal_foo özniteliği) aracılığıyla açığa çıkararak ele alır, ancak öznitelik ortağı uzantıları system/sepolicy/public desteklenmediğinden, bu yöntem satıcı politikası 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, onun yeni, AOSP olmayan satıcı bileşeniyle etkileşim biçimini değiştirmelidir.

Sistem görüntüsündeki politika, belirli satıcı özelleştirmeleri bilgisi olmadan yazılmalıdır. AOSP'deki belirli arayüzlere ilişkin politika bu nedenle system/sepolicy/public içindeki öznitelikler aracılığıyla açığa çıkarılır, böylece satıcı politikası bu öznitelikleri kullanan gelecekteki sistem politikasına dahil olabilir. Ancak, system/sepolicy/public dosyasındaki öznitelik uzantıları desteklenmez , bu nedenle sistem bileşenlerinin yeni satıcı bileşenleriyle nasıl etkileşimde bulunduğunu belirleyen tüm politikalar (ve bunlar, AOSP system/sepolicy/public dosyasında zaten mevcut olan öznitelikler tarafından ele alınmaz) device/ manufacturer / device-name /sepolicy konumunda olmalıdır. device/ manufacturer / device-name /sepolicy . Bu, sistem türlerinin, yalnızca çerçeve OTA'sının bir parçası olarak satıcı türlerine izin verilen erişimi değiştiremeyeceği anlamına gelir.