Politika uyumluluğu

Bu sayfada, Android'in yeni platform SELinux ayarlarının eski tedarikçi SELinux ayarlarından farklı olabileceği platform kablosuz (OTA) güncellemeleriyle ilgili politika uyumluluğu sorunlarını nasıl ele aldığı açıklanmaktadır.

Nesne sahipliği ve etiketleme

Platform ve satıcı politikalarını ayrı tutmak için her nesnenin sahipliği net bir şekilde tanımlanmalıdır. Örneğin, tedarikçi politikası /dev/foo etiketleri ve platform politikası /dev/foo etiketleri sonraki bir OTA'da yer alıyorsa beklenmedik bir ret gibi tanımlanmamış davranışlar veya daha da önemlisi başlatma hatası oluşur. SELinux için bu durum, etiketleme çakışması olarak ortaya çıkar. Cihaz düğümünde, en son uygulanan etikete çözümlenen tek bir etiket olabilir. Sonuç olarak:

• Başarısızlıkla uygulanan etikete erişmesi gereken işlemler kaynağa erişimi kaybeder.
• Dosyaya erişim kazanan işlemler, yanlış cihaz düğümü oluşturulduğu için bozulabilir.

Platform ve satıcı etiketleri arasındaki çakışmalar, özellikler, hizmetler, işlemler, dosyalar ve soketler dahil olmak üzere SELinux etiketi olan tüm nesnelerde meydana gelebilir. Bu sorunları önlemek için bu nesnelerin sahipliğini net bir şekilde tanımlayın.

Tür/özellik ad alanı

SELinux türü ve özellik adları, etiket çakışmalarına ek olarak da çakışabilir. SELinux, aynı tür ve özelliklerin birden fazla kez bildirilmesine izin vermez. Yinelenen beyanlara sahip bir politika derlenemez. Tür ve özellik adı çakışmalarını önlemek için tüm tedarikçi beyanlarının vendor_ önekiyle başlaması önemle tavsiye edilir. Örneğin, satıcılar type foo, domain; yerine type vendor_foo, domain; kullanmalıdır.

Dosya sahipliği

Platform ve satıcı politikası genellikle tüm dosya sistemleri için etiket sağladığından dosyalarla ilgili çakışmaları önlemek zordur. Tür adlandırmanın aksine, dosyaların ad alanına yerleştirilmesi pratik değildir. Çünkü dosyaların çoğu çekirdek tarafından oluşturulur. Bu çakışmaları önlemek için bu bölümdeki dosya sistemleriyle ilgili adlandırma yönergelerini uygulayın. Android 8.0'da bunlar teknik zorunluluk içermeyen önerilerdir. Bu öneriler gelecekte Vendor Test Suite (VTS) tarafından zorunlu kılınacaktır.

Sistem (/system)

Yalnızca sistem görüntüsü, /system bileşenleri için file_contexts, service_contexts vb. aracılığıyla etiket sağlamalıdır. /system bileşenleri için etiketler satıcı politikasına eklenirse yalnızca çerçeveye yönelik bir OTA güncellemesi mümkün olmayabilir.

Tedarikçi (/vendor)

AOSP SELinux politikası, platformun etkileşimde bulunduğu vendorbölümünün kısımlarını zaten etiketlemektedir. Bu sayede, platform işlemlerinin vendorbölümünün kısımlarıyla iletişim kurabilmesi veya bu kısımlara erişebilmesi için SELinux kuralları yazılabilir. Örnekler:

Bu nedenle, neverallows bölümündeki ek dosyalar etiketlenirken belirli kurallara uyulması (neverallows aracılığıyla zorunlu kılınır) gerekir:vendor

• vendor_file , vendor bölümündeki tüm dosyaların varsayılan etiketi olmalıdır. Platform politikası, passthrough HAL uygulamalarına erişmek için bu ayarın yapılmasını zorunlu kılar.
• Satıcı politikası aracılığıyla vendor bölümüne eklenen tüm yeni exec_types ürünlerinde vendor_file_type özelliği bulunmalıdır. Bu, neverallow'lar aracılığıyla zorunlu kılınır.
• Gelecekteki platform/çerçeve güncellemeleriyle çakışmaları önlemek için exec_types dışındaki dosyaları vendor bölümünde etiketlemeyin.
• AOSP tarafından aynı işlem HAL'leri olarak tanımlanan tüm kitaplık bağımlılıkları same_process_hal_file. olarak etiketlenmelidir.

Procfs (/proc)

/proc içindeki dosyalar yalnızca genfscon etiketi kullanılarak etiketlenebilir. Android 7.0'da, procfs içindeki dosyaları etiketlemek için hem platform hem de sağlayıcı politikası genfscon kullanıyordu.

Öneri: Yalnızca platform politikası etiketleri /proc. Tedarikçi süreçlerinin, şu anda varsayılan etiketle (proc) etiketlenmiş /proc içindeki dosyalara erişmesi gerekiyorsa tedarikçi politikası bunları açıkça etiketlememeli ve bunun yerine tedarikçi alan adları için kurallar eklemek üzere genel proc türünü kullanmalıdır. Bu sayede, platform güncellemeleri procfs üzerinden kullanıma sunulan gelecekteki çekirdek arayüzlerini destekleyebilir ve gerektiğinde bunları açıkça etiketleyebilir.

Debugfs (/sys/kernel/debug)

Debugfs, hem file_contexts hem de genfscon olarak etiketlenebilir. Android 7.0 ile Android 10'da hem platform hem de satıcı etiketi debugfs.

Android 11'de debugfs, üretim cihazlarında erişilemez veya bağlanamaz. Cihaz üreticileri debugfs öğesini kaldırmalıdır.

Tracefs (/sys/kernel/debug/tracing)

Tracefs, hem file_contexts hem de genfscon olarak etiketlenebilir. Android 7.0'da yalnızca platform etiketleri tracefs.

Öneri: Yalnızca platform, tracefs etiketini kullanabilir.

Sysfs (/sys)

/sys içindeki dosyalar hem file_contexts hem de genfscon kullanılarak etiketlenebilir. Android 7.0'da hem platform hem de satıcı, sysfs içindeki dosyaları etiketlemek için genfscon kullanır.

Öneri: Platform, cihaza özel olmayan sysfs düğümlerini etiketleyebilir. Aksi takdirde, dosyaları yalnızca satıcı etiketleyebilir.

tmpfs (/dev)

/dev klasöründeki dosyalar file_contexts içinde etiketlenebilir. Android 7.0'da hem platform hem de satıcı etiket dosyaları burada bulunur.

Öneri: Tedarikçi, yalnızca /dev/vendor (örneğin, /dev/vendor/foo, /dev/vendor/socket/bar) biçimindeki dosyaları etiketleyebilir.

Rootfs (/)

/ klasöründeki dosyalar file_contexts içinde etiketlenebilir. Android 7.0'da hem platform hem de satıcı etiket dosyaları burada yer alır.

Öneri: Yalnızca sistem, / içindeki dosyaları etiketleyebilir.

Veriler (/data)

Veriler, file_contexts ve seapp_contexts kombinasyonuyla etiketlenir.

Öneri: Satıcı etiketlemesine dışarıda izin vermeyin /data/vendor. Yalnızca platform, /data öğesinin diğer kısımlarını etiketleyebilir.

Genfs etiketleri sürümü

Tedarikçi API düzeyi 202504'ten itibaren, genfscon ile system/sepolicy/compat/plat_sepolicy_genfs_ver.cil içinde atanan yeni SELinux etiketleri, eski vendor bölümleri için isteğe bağlıdır. Bu sayede eski vendor bölümler mevcut SEPolicy uygulamalarını koruyabilir. Bu, /vendor/etc/selinux/genfs_labels_version.txt içinde depolanan Makefile değişkeni BOARD_GENFS_LABELS_VERSION tarafından kontrol edilir.

Örnek:

• Tedarikçi API düzeyi 202404'te /sys/class/udc düğümü varsayılan olarak sysfs şeklinde etiketlenir.
• Tedarikçi API düzeyi 202504'ten itibaren /sys/class/udc, sysfs_udc olarak etiketlenir.

Ancak /sys/class/udc, API düzeyi 202404'ü kullanan vendor bölümleri tarafından varsayılan sysfs etiketi veya tedarikçiye özel bir etiketle birlikte kullanılıyor olabilir. /sys/class/udc öğesini koşulsuz olarak sysfs_udc şeklinde etiketlemek, bu vendor bölümleriyle uyumluluğu bozabilir. BOARD_GENFS_LABELS_VERSION işaretlendiğinde platform, eski vendor bölümleri için önceki etiketleri ve izinleri kullanmaya devam eder.

BOARD_GENFS_LABELS_VERSION, tedarikçi API düzeyinden büyük veya bu düzeye eşit olabilir. Örneğin, vendor API düzeyi 202404'ü kullanan bölümler, 202504'te kullanıma sunulan yeni etiketleri benimsemek için BOARD_GENFS_LABELS_VERSION değerini 202504 olarak ayarlayabilir. 202504'e özel genfs etiketlerinin listesini inceleyin.

genfscon düğümleri etiketlenirken platform, eski vendor bölümleri dikkate almalı ve gerektiğinde uyumluluk için yedek mekanizmalar uygulamalıdır. Platform, genfs etiketleri sürümünü sorgulamak için yalnızca platforma ait kitaplıkları kullanabilir.

• Yerel reklamlar için libgenfslabelsversion kullanın. libgenfslabelsversion'nin üstbilgi dosyası için genfslabelsversion.h başlıklı makaleye bakın.
• Java'da android.os.SELinux.getGenfsLabelsVersion() kullanın.

Platform-kamu politikası

Platform SELinux politikası, özel ve herkese açık olarak ikiye ayrılır. Platform-public politikası, platform ile satıcı arasında API görevi gören, satıcı API düzeyinde her zaman kullanılabilen tür ve özelliklerden oluşur. Bu politika, satıcıların satıcı politikası dosyaları oluşturabilmesi için satıcı politikası yazarlarına sunulur. Bu dosyalar, platforma özel politika ile birleştirildiğinde cihaz için tam işlevsel bir politika oluşturulur. Platformun kamu politikası system/sepolicy/public adresinde tanımlanmıştır.

Örneğin, tedarikçi bağlamında başlatma sürecini temsil eden vendor_init türü, system/sepolicy/public/vendor_init.te altında tanımlanır:

type vendor_init, domain;

Tedarikçiler, özel politika kuralları yazmak için vendor_init türüne başvurabilir:

# Allow vendor_init to set vendor_audio_prop in vendor's init scripts
set_prop(vendor_init, vendor_audio_prop)

Uyumluluk özellikleri

SELinux politikası, belirli nesne sınıfları ve izinler için kaynak ve hedef türler arasındaki etkileşimdir. SELinux politikasından etkilenen her nesne (ör. işlemler, dosyalar) yalnızca bir türe sahip olabilir ancak bu türün birden fazla özelliği olabilir.

Politika, çoğunlukla mevcut türler açısından yazılmıştır. Burada hem vendor_init hem de debugfs türdür:

allow vendor_init debugfs:dir { mounton };

Bu, politika tüm türler hakkında bilgi sahibi olunarak yazıldığı için işe yarar. Ancak, satıcı politikası ve platform politikası belirli türleri kullanıyorsa ve belirli bir nesnenin etiketi bu politikalardan yalnızca birinde değişiyorsa diğerinde, daha önce erişim kazanmış veya kaybetmiş politika bulunabilir. Örneğin, platform politikasının sysfs düğümlerini sysfs olarak etiketlediğini varsayalım:

/sys(/.*)? u:object_r:sysfs:s0

Sağlayıcı politikası, /sys/usb olarak etiketlenen sysfs erişim izni verir:

allow vendor_init sysfs:chr_file rw_file_perms;

Platform politikası, /sys/usb öğesini sysfs_usb olarak etiketleyecek şekilde değiştirilirse satıcı politikası aynı kalır ancak yeni sysfs_usb türü için politika olmadığından vendor_init, /sys/usb öğesine erişimini kaybeder:

/sys/usb u:object_r:sysfs_usb:s0

Android, bu sorunu çözmek için sürüm oluşturulmuş özellikler kavramını sunar. Derleme sırasında, derleme sistemi, tedarikçi politikasında kullanılan platform herkese açık türlerini otomatik olarak bu sürüm oluşturulmuş özelliklere çevirir. Bu çeviri, sürüm oluşturulmuş bir özelliği platformdaki bir veya daha fazla genel türle ilişkilendiren dosyalara eşleme yapılarak etkinleştirilir.

Örneğin, /sys/usb'nın 202504 platform politikasında sysfs olarak etiketlendiğini ve 202504 tedarikçi politikasının /sys/usb'ya vendor_init erişimi verdiğini varsayalım. Bu durumda:

• Satıcı politikası, allow vendor_init sysfs:chr_file rw_file_perms; kuralını yazar. Bunun nedeni, /sys/usb öğesinin 202504 platform politikasında sysfs olarak etiketlenmesidir. Derleme sistemi, satıcı politikasını derlediğinde kuralı otomatik olarak allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms;'ya çevirir. vendor_init_202504 ve sysfs_202504 özellikleri, platform tarafından tanımlanan türler olan vendor_init ve sysfs türlerine karşılık gelir.
• Derleme sistemi bir kimlik eşleme dosyası oluşturur /system/etc/selinux/mapping/202504.cil. Hem system hem de vendor bölümleri aynı 202504 sürümünü kullandığından eşleme dosyası, type_202504 ile type arasındaki kimlik eşlemelerini içerir. Örneğin, vendor_init_202504, vendor_init ile eşlenmiş ve sysfs_202504, sysfs ile eşlenmiş:

  (typeattributeset sysfs_202504 (sysfs))
  (typeattributeset vendor_init_202504 (vendor_init))
  ...

Sürüm 202504'ten 202604'e yükseltildiğinde, 202504 vendor bölümleri için system/sepolicy/private/compat/202504/202504.cil altında yeni bir eşleme dosyası oluşturulur. Bu dosya, 202604 veya daha yeni system bölümleri için /system/etc/selinux/mapping/202504.cil'ye yüklenir. Başlangıçta bu eşleme dosyası, daha önce açıklandığı gibi kimlik eşlemelerini içerir. 202604 platform politikasına sysfs_usb için yeni bir etiket /sys/usb eklenirse eşleme dosyası, sysfs_202504 öğesini sysfs_usb ile eşleyecek şekilde güncellenir:

(typeattributeset sysfs_202504 (sysfs sysfs_usb))
(typeattributeset vendor_init_202504 (vendor_init))
...

Bu güncelleme, dönüştürülen tedarikçi politikası kuralı allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms;'nın yeni sysfs_usb türüne otomatik olarak vendor_init erişimi vermesine olanak tanır.

Eski vendor bölümleriyle uyumluluğu korumak için yeni bir herkese açık tür eklendiğinde bu tür, eşleme dosyasındaki system/sepolicy/private/compat/ver/ver.cil sürüm oluşturulmuş özelliklerden en az biriyle eşlenmeli veya önceki satıcı sürümlerinde eşleşen tür olmadığını belirtmek için system/sepolicy/private/compat/ver/ver.ignore.cil altında listelenmelidir.

Platform politikası, sağlayıcı politikası ve eşleme dosyasının birleşimi, sistemin sağlayıcı politikası güncellenmeden güncellenmesine olanak tanır. Ayrıca, sürüm oluşturulmuş özelliklere dönüştürme işlemi otomatik olarak gerçekleşir. Bu nedenle, satıcı politikasının sürüm oluşturma işlemini yapması gerekmez ve herkese açık türler olduğu gibi kullanılmaya devam edilir.

system_ext public and product public policy

Android 11'den itibaren system_ext ve product bölümlerinin, belirlenen herkese açık türlerini vendor bölümüne aktarmasına izin verilir. Platform kamu politikası gibi, tedarikçi politikası da türleri ve kuralları otomatik olarak sürüm oluşturulmuş özelliklere çevirir. Örneğin, type öğesini type_ver öğesine çevirir. Burada ver, vendor bölümünün tedarikçi API düzeyidir.

system_ext ve product bölümleri aynı platform sürümüne ver dayandığında derleme sistemi, type ile type_ver arasındaki kimlik eşlemelerini içeren system_ext/etc/selinux/mapping/ver.cil ve product/etc/selinux/mapping/ver.cil için temel eşleme dosyaları oluşturur. Tedarikçi politikası, sürüm oluşturulmuş özellik type_ver ile type'ya erişebilir.

Yalnızca system_ext ve product bölümleri güncellenirse (ör. ver'den ver+1'e veya daha sonraki bir sürüme) ve vendor bölümü ver sürümünde kalırsa tedarikçi politikası, system_ext ve product bölüm türlerine erişimini kaybedebilir. Bozulmayı önlemek için system_ext ve product bölümleri, somut türlerden type_ver özelliklerine eşleme dosyaları sağlamalıdır. ver vendor bölümünü ver+1 (veya sonraki sürümler) system_ext ve product bölümleriyle destekleyen iş ortakları, eşleme dosyalarını korumakla yükümlüdür.

Eşleme dosyalarını system_ext ve product bölümlerine yüklemek için cihaz uygulayıcılarının veya tedarikçilerin şunları yapması beklenir:

1. Oluşturulan temel eşleme dosyalarını ver system_ext ve product bölümlerinden kaynak ağaçlarına kopyalayın.
2. Eşleme dosyalarını gerektiği gibi değiştirin.
3. ver+1 (veya sonraki) system_ext ve product bölümlerine eşleme dosyalarını yükleyin.

Örneğin, 202504 system_ext bölümünde foo_type adlı bir genel tür olduğunu varsayalım. Ardından system_ext/etc/selinux/mapping/202504.cil 202504 system_ext bölümünde şu şekilde görünür:

(typeattributeset foo_type_202504 (foo_type))
(expandtypeattribute foo_type_202504 true)
(typeattribute foo_type_202504)

bar_type, 202604 system_ext bölümüne eklenirse ve 202504 vendor bölümü için bar_type, foo_type ile eşlenmesi gerekiyorsa 202504.cil, (typeattributeset foo_type_202504 (foo_type)) değerinden (typeattributeset foo_type_202504 (foo_type bar_type)) değerine güncellenebilir ve ardından 202604 system_ext bölümüne yüklenebilir. 202504 vendor bölümü, 202604 system_ext bölümünün foo_type ve bar_type öğelerine erişmeye devam edebilir.

Android 9'daki özellik değişiklikleri

Android 9'a yükseltme yapan cihazlar aşağıdaki özellikleri kullanabilir ancak Android 9 ile kullanıma sunulan cihazlar kullanamaz.

İhlal eden kullanıcı özellikleri

Android 9, alanla ilgili şu özellikleri içerir:

• data_between_core_and_vendor_violators. vendor ile coredomains arasında dosyaların yola göre paylaşılmaması şartını ihlal eden tüm alan adları için özellik. Platform ve tedarikçi süreçleri, iletişim kurmak için diskteki dosyaları kullanmamalıdır (kararsız ABI). Öneri:
  • Tedarikçi kodu /data/vendor kullanmalıdır.
  • Sistemde /data/vendor kullanılmamalıdır.
• system_executes_vendor_violators. Satıcı ikililerinin yürütülmemesi şartını ihlal eden tüm sistem alanları (init ve shell domains hariç) için özellik. Tedarikçi ikili dosyalarının yürütülmesinde kararsız API var. Platform, satıcı ikililerini doğrudan çalıştırmamalıdır. Öneri:
  • Satıcı ikililerine yönelik bu tür platform bağımlılıkları, HIDL HAL'lerinin arkasında olmalıdır.

    VEYA

  • coredomains bölümüne taşınmalı ve böylece coredomain olmaktan çıkmalıdır.vendor

Güvenilmeyen özellikler

Rastgele kod barındıran güvenilmeyen uygulamaların, bu tür uygulamalardan erişim için yeterince güvenli olduğu düşünülenler dışında HwBinder hizmetlerine erişimi olmamalıdır (aşağıdaki güvenli hizmetlere bakın). Bunun iki temel nedeni vardır:

1. HIDL şu anda arayanın UID bilgilerini göstermediğinden HwBinder sunucuları istemci kimlik doğrulaması yapmaz. HIDL bu tür verileri kullanıma sunsa bile birçok HwBinder hizmeti uygulamaların altında bir düzeyde çalışır (ör. HAL'ler) veya yetkilendirme için uygulama kimliğine güvenmemelidir. Bu nedenle, güvenli olması için varsayılan olarak her HwBinder hizmetinin, tüm istemcilerine hizmet tarafından sunulan işlemleri gerçekleştirmek için eşit derecede yetkiliymiş gibi davrandığı kabul edilir.
2. HAL sunucuları (HwBinder hizmetlerinin bir alt kümesi), system/core bileşenlerine kıyasla daha yüksek güvenlik sorunları sıklığına sahip kod içerir ve yığının alt katmanlarına (donanıma kadar) erişebilir. Bu nedenle, Android güvenlik modelini atlama fırsatları artar.

Güvenli hizmetler

Güvenli hizmetler şunlardır:

• same_process_hwservice. Bu hizmetler (tanım gereği) istemci sürecinde çalışır ve bu nedenle, sürecin çalıştığı istemci alanıyla aynı erişime sahiptir.
• coredomain_hwservice. Bu hizmetler, 2. nedene bağlı riskler oluşturmaz.
• hal_configstore_ISurfaceFlingerConfigs. Bu hizmet, herhangi bir alan tarafından kullanılmak üzere özel olarak tasarlanmıştır.
• hal_graphics_allocator_hwservice. Bu işlemler, uygulamaların erişmesine izin verilen surfaceflinger Binder hizmeti tarafından da sunulur.
• hal_omx_hwservice. Bu, uygulamaların erişmesine izin verilen mediacodec Binder hizmetinin HwBinder sürümüdür.
• hal_codec2_hwservice. Bu, hal_omx_hwservice uygulamasının daha yeni bir sürümüdür.

Kullanılabilir özellikler

Güvenli olmadığı düşünülen tüm hwservices öğelerinde untrusted_app_visible_hwservice özelliği bulunur. İlgili HAL sunucularında untrusted_app_visible_halserver özelliği bulunur. Android 9 ile kullanıma sunulan cihazlar untrusted özelliğini KULLANMAMALIDIR.

Öneri:

• Güvenilmeyen uygulamalar bunun yerine, satıcı HIDL HAL ile iletişim kuran bir sistem hizmetiyle iletişim kurmalıdır. Örneğin, uygulamalar binderservicedomain ile iletişim kurabilir, ardından mediaserver (binderservicedomain olan) sırayla hal_graphics_allocator ile iletişim kurar.

  VEYA

• vendor HAL'lerine doğrudan erişmesi gereken uygulamaların kendi tedarikçi tanımlı sepolicy alanları olmalıdır.

Dosya özelliği testleri

Android 9, belirli konumlardaki tüm dosyaların uygun özelliklere (ör. sysfs içindeki tüm dosyaların gerekli sysfs_type özelliğine) sahip olmasını sağlayan derleme zamanı testleri içerir.

SELinux bağlamları etiketleme

Platform ve satıcı sepolicy arasındaki ayrımı desteklemek için sistem, SELinux bağlam dosyalarını ayrı tutmak üzere farklı şekilde oluşturur.

Dosya bağlamları

Android 8.0, file_contexts için aşağıdaki değişiklikleri getirmiştir:

• Önyükleme sırasında cihazda ek derleme yükünü önlemek için, file_contexts ikili biçimde var olmamalıdır. Bunun yerine, {property, service}_contexts gibi okunabilir, normal ifade metin dosyalarıdır (7.0 sürümünden önceki gibi).
• file_contexts iki dosyaya bölünür:
  • plat_file_contexts
    • Android platformu file_context. /vendor bölümünün, sepolicy dosyalarının düzgün çalışmasını sağlamak için hassas bir şekilde etiketlenmesi gereken kısımları dışında cihaza özel etiketler içermez.
    • Cihazda system bölümünde /system/etc/selinux/plat_file_contexts konumunda bulunmalı ve başlangıçta init tarafından satıcı file_context ile birlikte yüklenmelidir.
  • vendor_file_contexts
    • Cihaza özel file_context, cihazın Boardconfig.mk dosyalarındaki BOARD_SEPOLICY_DIRS ile işaret edilen dizinlerde bulunan file_contexts birleştirilerek oluşturulur.
    • vendor bölümünde /vendor/etc/selinux/vendor_file_contexts konumuna yüklenmeli ve platform file_context ile birlikte başlangıçta init tarafından yüklenmelidir.

Tesis bağlamları

Android 8.0'da property_contexts iki dosya arasında bölünmüştür:

• plat_property_contexts
  • Cihaza özel etiketleri olmayan property_context Android platformu.
  • system bölümünde /system/etc/selinux/plat_property_contexts konumunda bulunmalı ve başlangıçta satıcı property_contexts ile birlikte init tarafından yüklenmelidir.
• vendor_property_contexts
  • Cihaza özel property_context, cihazın Boardconfig.mk dosyalarındaki BOARD_SEPOLICY_DIRS ile işaret edilen dizinlerde bulunan property_contexts birleştirilerek oluşturulur.
  • vendor bölümünde /vendor/etc/selinux/vendor_property_contexts konumunda bulunmalı ve platform property_context ile birlikte başlangıçta init tarafından yüklenmelidir.

Hizmet bağlamları

Android 8.0'da service_contexts aşağıdaki dosyalara bölünmüştür:

• plat_service_contexts
  • Android platformuna özgü service_context için servicemanager. service_context öğesinin cihaza özel etiketleri yoktur.
  • system bölümünde /system/etc/selinux/plat_service_contexts konumunda bulunmalı ve başlangıçta satıcı service_contexts ile birlikte servicemanager tarafından yüklenmelidir.
• vendor_service_contexts
  • Cihaza özel service_context, cihazın Boardconfig.mk dosyalarındaki BOARD_SEPOLICY_DIRS ile işaret edilen dizinlerde bulunan service_contexts birleştirilerek oluşturulur.
  • vendor bölümünde /vendor/etc/selinux/vendor_service_contexts konumunda bulunmalı ve başlangıçta platform service_contexts ile birlikte servicemanager tarafından yüklenmelidir.
  • servicemanager, bu dosyayı başlatma sırasında arasa da, TREBLE cihazının tamamen uyumlu olması için vendor_service_contexts dosyası mevcut OLMAMALIDIR. Bunun nedeni, vendor ile system arasındaki tüm etkileşimlerin hwservicemanager/hwbinder üzerinden geçmesi GEREKMESİDİR.
• plat_hwservice_contexts
  • Cihaza özel etiketleri olmayan hwservice_context için Android platformu hwservicemanager.
  • system bölümünde /system/etc/selinux/plat_hwservice_contexts konumunda bulunmalı ve başlangıçta hwservicemanager tarafından vendor_hwservice_contexts ile birlikte yüklenmelidir.
• vendor_hwservice_contexts
  • Cihaza özel hwservice_context, cihazın Boardconfig.mk dosyalarındaki BOARD_SEPOLICY_DIRS ile işaret edilen dizinlerde bulunan hwservice_contexts birleştirilerek oluşturulur.
  • vendor bölümünde /vendor/etc/selinux/vendor_hwservice_contexts konumunda bulunmalı ve hwservicemanager tarafından başlangıçta plat_service_contexts ile birlikte yüklenmelidir.
• vndservice_contexts
  • Cihaza özel service_context için vndservicemanager, birleştirilerek oluşturulan vndservice_contexts, cihazın Boardconfig.mk içindeki BOARD_SEPOLICY_DIRS tarafından işaret edilen dizinlerde bulunur.
  • Bu dosya, vendor bölümünde /vendor/etc/selinux/vndservice_contexts konumunda bulunmalı ve başlangıçta vndservicemanager tarafından yüklenmelidir.

Seapp bağlamları

Android 8.0'da seapp_contexts iki dosya arasında bölünmüştür:

• plat_seapp_contexts
  • Cihaza özel değişiklikler içermeyen Android platformu seapp_context.
  • /system/etc/selinux/plat_seapp_contexts. konumundaki system bölümünde bulunmalıdır.
• vendor_seapp_contexts
  • Cihazın Boardconfig.mk dosyalarındaki BOARD_SEPOLICY_DIRS tarafından işaret edilen dizinlerde bulunan seapp_contexts birleştirilerek oluşturulan, platform seapp_context için cihaza özel uzantı.
  • /vendor/etc/selinux/vendor_seapp_contexts adresindeki vendor bölümünde bulunmalıdır.

MAC izinleri

Android 8.0'da mac_permissions.xml iki dosya arasında bölünmüştür:

• Platform mac_permissions.xml
  • Cihaza özel değişiklikler içermeyen mac_permissions.xml Android platformu.
  • /system/etc/selinux/. konumundaki system bölümünde bulunmalıdır.
• Platform Dışı mac_permissions.xml
  • Cihaza özel platform uzantısı mac_permissions.xml cihazın Boardconfig.mk dosyalarındaki BOARD_SEPOLICY_DIRS tarafından işaret edilen dizinlerde bulunan mac_permissions.xml kullanılarak oluşturulur.
  • /vendor/etc/selinux/. konumundaki vendor bölümünde bulunmalıdır.