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:
- En son Android çekirdeğini kullanın.
- En az ayrıcalık ilkesini benimseyin.
- Android'e yalnızca kendi eklemelerinizi yapın. Varsayılan politika, Android Açık Kaynak Projesi kod tabanıyla otomatik olarak çalışır.
- Yazılım bileşenlerini tekil görevleri yürüten modüller halinde bölümlere ayırın.
- Bu görevleri ilgisiz işlevlerden ayıran SELinux ilkeleri oluşturun.
- 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çinBOARD_SEPOLICY
değişkenlerini kullanın. - 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. - Sonuçları analiz edin ve alan tanımlarınızı hassaslaştırın.
- 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.
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'nın parçası olarak satıcı türlerine izin verilen erişimi değiştiremeyeceği anlamına gelir.