Compatibilità con le norme

Questa pagina descrive come Android gestisce i problemi di compatibilità delle norme con gli aggiornamenti della piattaforma over-the-air (OTA), in cui le nuove impostazioni SELinux della piattaforma potrebbero differire dalle vecchie impostazioni SELinux del fornitore.

Proprietà ed etichettatura degli oggetti

La proprietà deve essere definita chiaramente per ogni oggetto per mantenere separate le norme della piattaforma e del fornitore. Ad esempio, se le etichette delle norme del fornitore /dev/foo e le etichette delle norme della piattaforma /dev/foo in un OTA successivo, si verifica un comportamento indefinito come un rifiuto imprevisto o, in modo più critico, un errore di avvio. Per SELinux, questo si manifesta come una collisione di etichette. Il nodo del dispositivo può avere una sola etichetta che viene risolta nell'ultima etichetta applicata. Ne consegue che:

• I processi che necessitano dell'accesso all'etichetta applicata senza esito perdono l'accesso alla risorsa.
• I processi che ottengono l'accesso al file potrebbero interrompersi perché è stato creato il nodo del dispositivo errato.

Possono verificarsi conflitti tra le etichette della piattaforma e del fornitore per qualsiasi oggetto con un'etichetta SELinux, tra cui proprietà, servizi, processi, file e socket. Per evitare questi problemi, definisci chiaramente la proprietà di questi oggetti.

Spazio dei nomi di tipo/attributo

Oltre alle collisioni di etichette, possono verificarsi anche collisioni tra i nomi di tipi e attributi SELinux. SELinux non consente più dichiarazioni degli stessi tipi e attributi. Una policy con dichiarazioni duplicate non viene compilata. Per evitare conflitti tra nomi di tipi e attributi, è consigliabile che tutte le dichiarazioni del fornitore inizino con il prefisso vendor_. Ad esempio, i fornitori devono utilizzare type vendor_foo, domain; anziché type foo, domain;.

Proprietà dei file

Evitare le collisioni per i file è difficile perché le norme della piattaforma e del fornitore forniscono comunemente etichette per tutti i file system. A differenza della denominazione dei tipi, lo spazio dei nomi dei file non è pratico, poiché molti di questi vengono creati dal kernel. Per evitare questi conflitti, segui le indicazioni per la denominazione dei file system in questa sezione. Per Android 8.0, questi sono consigli senza applicazione tecnica. In futuro, questi consigli verranno applicati dalla Vendor Test Suite (VTS).

Sistema (/system)

Solo l'immagine di sistema deve fornire etichette per i componenti /system tramite file_contexts, service_contexts e così via. Se le etichette per i componenti /system vengono aggiunte nelle norme del fornitore, un aggiornamento OTA solo del framework potrebbe non essere possibile.

Fornitore (/vendor)

Il criterio SELinux AOSP etichetta già le parti della partizione vendor con cui interagisce la piattaforma, il che consente di scrivere regole SELinux per i processi della piattaforma in modo che possano comunicare o accedere a parti della partizione vendor. Esempi:

Di conseguenza, quando etichetti file aggiuntivi nella partizione vendor, devi seguire regole specifiche (applicate tramite neverallows):

• vendor_file deve essere l'etichetta predefinita per tutti i file nella partizione vendor. Il criterio della piattaforma richiede questo per accedere alle implementazioni HAL passthrough.
• Tutti i nuovi exec_types aggiunti nella partizione vendor tramite le norme del fornitore devono avere l'attributo vendor_file_type. Questa operazione viene applicata tramite neverallows.
• Per evitare conflitti con futuri aggiornamenti della piattaforma/del framework, evita di etichettare file diversi da exec_types nella partizione vendor.
• Tutte le dipendenze della libreria per gli HAL dello stesso processo identificati da AOSP devono essere etichettate come same_process_hal_file.

Procfs (/proc)

I file in /proc possono essere etichettati solo utilizzando l'etichetta genfscon. In Android 7.0, sia i criteri della piattaforma sia quelli del fornitore utilizzati genfscon per etichettare i file in procfs.

Suggerimento: solo etichette dei criteri della piattaforma /proc. Se le procedure del fornitore devono accedere ai file in /proc che attualmente sono etichettati con l'etichetta predefinita (proc), le norme del fornitore non devono etichettarli esplicitamente e devono invece utilizzare il tipo generico proc per aggiungere regole per i domini dei fornitori. In questo modo, gli aggiornamenti della piattaforma possono adattarsi alle future interfacce del kernel esposte tramite procfs ed etichettarle esplicitamente in base alle necessità.

Debugfs (/sys/kernel/debug)

Debugfs può essere etichettato sia in file_contexts che in genfscon. In Android 7.0 - Android 10, sia l'etichetta della piattaforma sia quella del fornitore debugfs.

In Android 11, debugfs non può essere acceduto o montato sui dispositivi di produzione. I produttori di dispositivi devono rimuovere debugfs.

Tracefs (/sys/kernel/debug/tracing)

Tracefs può essere etichettato sia in file_contexts che in genfscon. In Android 7.0, solo le etichette della piattaforma tracefs.

Consiglio:solo la piattaforma può etichettare tracefs.

Sysfs (/sys)

I file in /sys possono essere etichettati utilizzando sia file_contexts sia genfscon. In Android 7.0, sia la piattaforma che il fornitore utilizzano genfscon per etichettare i file in sysfs.

Consiglio:la piattaforma potrebbe etichettare i nodi sysfs che non sono specifici per dispositivo. In caso contrario, solo il fornitore può etichettare i file.

tmpfs (/dev)

I file in /dev potrebbero essere etichettati in file_contexts. In Android 7.0, sia la piattaforma che i file delle etichette del fornitore qui.

Consiglio:il fornitore può etichettare solo i file in /dev/vendor (ad esempio, /dev/vendor/foo, /dev/vendor/socket/bar).

Rootfs (/)

I file in / potrebbero essere etichettati in file_contexts. In Android 7.0, entrambi i file di etichette della piattaforma e del fornitore qui.

Consiglio:solo il sistema può etichettare i file in /.

Dati (/data)

I dati vengono etichettati tramite una combinazione di file_contexts e seapp_contexts.

Consiglio:non consentire l'etichettatura del fornitore al di fuori di /data/vendor. Solo la piattaforma può etichettare altre parti di /data.

Versione delle etichette Genfs

A partire dal livello API fornitore 202504, le etichette SELinux più recenti assegnate con genfscon in system/sepolicy/compat/plat_sepolicy_genfs_ver.cil sono facoltative per le partizioni vendor precedenti. Ciò consente alle partizioni vendor meno recenti di mantenere l'implementazione SEPolicy esistente. Questa operazione è controllata dalla variabile Makefile BOARD_GENFS_LABELS_VERSION che è archiviata in /vendor/etc/selinux/genfs_labels_version.txt.

Esempio:

• Nel livello API fornitore 202404, il nodo /sys/class/udc è etichettato sysfs per impostazione predefinita.
• A partire dal livello API fornitore 202504, /sys/class/udc è etichettato sysfs_udc.

Tuttavia, /sys/class/udc potrebbe essere in uso da partizioni vendor che utilizzano il livello API 202404, con l'etichetta sysfs predefinita o un'etichetta specifica del fornitore. L'etichettatura incondizionata di /sys/class/udc come sysfs_udc potrebbe compromettere la compatibilità con queste partizioni vendor. Se selezioni BOARD_GENFS_LABELS_VERSION, la piattaforma continua a utilizzare le etichette e le autorizzazioni precedenti per le partizioni vendor precedenti.

BOARD_GENFS_LABELS_VERSION può essere maggiore o uguale al livello API del fornitore. Ad esempio, le partizioni vendor che utilizzano il livello API 202404 possono impostare BOARD_GENFS_LABELS_VERSION su 202504 per adottare le nuove etichette introdotte in 202504. Consulta l'elenco delle etichette genfs specifiche per il 202504.

Quando etichetta i nodi genfscon, la piattaforma deve prendere in considerazione le partizioni vendor precedenti e implementare meccanismi di fallback per la compatibilità, se necessario. La piattaforma può utilizzare librerie solo per la piattaforma per eseguire query sulla versione delle etichette genfs.

• Per gli annunci nativi, utilizza libgenfslabelsversion. Consulta genfslabelsversion.h per il file di intestazione di libgenfslabelsversion.
• In Java, utilizza android.os.SELinux.getGenfsLabelsVersion().

Norme pubbliche della piattaforma

Le norme SELinux della piattaforma sono suddivise in private e pubbliche. Le norme pubbliche della piattaforma sono costituite da tipi e attributi sempre disponibili per un livello API fornitore, che funge da API tra la piattaforma e il fornitore. Questo criterio è esposto agli autori di criteri dei fornitori per consentire a questi ultimi di creare file di criteri dei fornitori che, se combinati con il criterio privato della piattaforma, danno origine a un criterio completamente funzionale per un dispositivo. La norma pubblica della piattaforma è definita in system/sepolicy/public.

Ad esempio, un tipo vendor_init, che rappresenta il processo init nel contesto del fornitore, è definito in system/sepolicy/public/vendor_init.te:

type vendor_init, domain;

I fornitori possono fare riferimento al tipo vendor_init per scrivere regole personalizzate per le norme:

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

Attributi di compatibilità

Le norme SELinux sono un'interazione tra i tipi di origine e di destinazione per classi di oggetti e autorizzazioni specifiche. Ogni oggetto (ad esempio processi, file) interessato dai criteri SELinux può avere un solo tipo, ma questo tipo potrebbe avere più attributi.

La policy è scritta principalmente in termini di tipi esistenti. In questo caso, sia vendor_init che debugfs sono tipi:

allow vendor_init debugfs:dir { mounton };

Questo funziona perché le norme sono state scritte tenendo conto di tutti i tipi. Tuttavia, se le norme del fornitore e della piattaforma utilizzano tipi specifici e l'etichetta di un oggetto specifico cambia solo in una di queste norme, l'altra potrebbe contenere norme che si basano sull'accesso ottenuto o perso in precedenza. Ad esempio, supponiamo che le etichette delle norme della piattaforma contrassegnino i nodi sysfs come sysfs:

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

Le norme relative ai fornitori concedono l'accesso a /sys/usb, etichettato come sysfs:

allow vendor_init sysfs:chr_file rw_file_perms;

Se la policy della piattaforma viene modificata per etichettare /sys/usb come sysfs_usb, la policy del fornitore rimane invariata, ma vendor_init perde l'accesso a /sys/usb a causa della mancanza di una policy per il nuovo tipo sysfs_usb:

/sys/usb u:object_r:sysfs_usb:s0

Per risolvere questo problema, Android introduce il concetto di attributi con controllo delle versioni. In fase di compilazione, il sistema di build traduce automaticamente i tipi pubblici della piattaforma utilizzati nella norma del fornitore in questi attributi con controllo delle versioni. Questa traduzione è attivata da file di mapping che associano un attributo con controllo delle versioni a uno o più tipi pubblici della piattaforma.

Ad esempio, supponiamo che /sys/usb sia etichettato come sysfs nelle norme della piattaforma 202504 e che le norme del fornitore 202504 concedano l'accesso vendor_init a /sys/usb. In questo caso:

• I criteri del fornitore scrivono una regola allow vendor_init sysfs:chr_file rw_file_perms; perché /sys/usb è etichettato come sysfs nei criteri della piattaforma 202504. Quando il sistema di build compila la policy del fornitore, traduce automaticamente la regola in allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms;. Gli attributi vendor_init_202504 e sysfs_202504 corrispondono ai tipi vendor_init e sysfs, che sono i tipi definiti dalla piattaforma.
• Il sistema di compilazione genera un file di mappatura delle identità /system/etc/selinux/mapping/202504.cil. Poiché le partizioni system e vendor utilizzano la stessa versione 202504, il file di mappatura contiene le mappature delle identità da type_202504 a type. Ad esempio, vendor_init_202504 è mappato a vendor_init e sysfs_202504 è mappato a sysfs:

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

Quando la versione viene incrementata da 202504 a 202604, viene creato un nuovo file di mappatura per le partizioni 202504 vendor in system/sepolicy/private/compat/202504/202504.cil, che viene installato in /system/etc/selinux/mapping/202504.cil per le partizioni 202604 o successive system. Inizialmente, questo file di mappatura contiene le mappature delle identità, come descritto in precedenza. Se al criterio della piattaforma 202604 viene aggiunta una nuova etichetta sysfs_usb per /sys/usb, il file di mapping viene aggiornato per mappare sysfs_202504 a sysfs_usb:

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

Questo aggiornamento consente alla regola dei criteri del fornitore convertita allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms; di concedere automaticamente l'accesso vendor_init al nuovo tipo sysfs_usb.

Per mantenere la compatibilità con le partizioni vendor precedenti, ogni volta che viene aggiunto un nuovo tipo pubblico, questo deve essere mappato ad almeno uno degli attributi con controllo delle versioni nel file di mapping system/sepolicy/private/compat/ver/ver.cil o essere elencato in system/sepolicy/private/compat/ver/ver.ignore.cil per indicare che non esiste un tipo corrispondente nelle versioni precedenti del fornitore.

La combinazione del criterio della piattaforma, del criterio del fornitore e del file di mapping consente al sistema di aggiornarsi senza aggiornare il criterio del fornitore. Inoltre, la conversione negli attributi con controllo delle versioni avviene automaticamente, quindi le norme del fornitore non devono occuparsi del controllo delle versioni, ma continuare a utilizzare i tipi pubblici così come sono.

system_ext public and product public policy

A partire da Android 11, le partizioni system_ext e product possono esportare i tipi pubblici designati nella partizione vendor. Come le norme pubbliche della piattaforma, le norme del fornitore utilizzano tipi e regole tradotti automaticamente negli attributi con controllo delle versioni, ad esempio da type a type_ver, dove ver è il livello API del fornitore della partizione vendor.

Quando le partizioni system_ext e product si basano sulla stessa versione della piattaforma ver, il sistema di build genera file di mappatura di base in system_ext/etc/selinux/mapping/ver.cil e product/etc/selinux/mapping/ver.cil, che contengono mappature delle identità da type a type_ver. Il criterio del fornitore può accedere a type con l'attributo con controllo delle versioni type_ver.

Nel caso in cui vengano aggiornate solo le partizioni system_ext e product, ad esempio da ver a ver+1 (o versioni successive), mentre la partizione vendor rimane a ver, le norme del fornitore potrebbero perdere l'accesso ai tipi di partizioni system_ext e product. Per evitare interruzioni, le partizioni system_ext e product devono fornire file di mapping dai tipi concreti agli attributi type_ver. Ogni partner è responsabile della manutenzione dei file di mapping, se supporta la partizione ver vendor con ver+1 (o versioni successive) system_ext e le partizioni product.

Per installare i file di mapping nelle partizioni system_ext e product, gli implementatori di dispositivi o i fornitori devono:

1. Copia i file di mapping di base generati dalle partizioni ver system_ext e product nell'albero di origine.
2. Modifica i file di mappatura in base alle necessità.
3. Installa i file di mapping su ver+1 (o versioni successive) system_ext e partizioni product.

Ad esempio, supponiamo che la partizione 202504 system_ext abbia un tipo pubblico denominato foo_type. Poi system_ext/etc/selinux/mapping/202504.cil nella partizione 202504 system_ext sarà simile a questo:

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

Se bar_type viene aggiunto alla partizione 202604 system_ext e se bar_type deve essere mappato a foo_type per la partizione 202504 vendor, 202504.cil può essere aggiornato da (typeattributeset foo_type_202504 (foo_type)) a (typeattributeset foo_type_202504 (foo_type bar_type)) e poi installato nella partizione 202604 system_ext. La partizione 202504 vendor può continuare ad accedere a foo_type e bar_type della partizione 202604 system_ext.

Modifiche agli attributi per Android 9

I dispositivi che eseguono l'upgrade ad Android 9 possono utilizzare i seguenti attributi, ma i dispositivi che vengono lanciati con Android 9 non devono farlo.

Attributi del violatore

Android 9 include i seguenti attributi correlati al dominio:

• data_between_core_and_vendor_violators. Attributo per tutti i domini che violano il requisito di non condividere file per percorso tra vendor e coredomains. I processi della piattaforma e del fornitore non devono utilizzare file su disco per comunicare (ABI instabile). Consiglio:
  • Il codice fornitore deve utilizzare /data/vendor.
  • Il sistema non deve utilizzare /data/vendor.
• Attributo system_executes_vendor_violators per tutti i domini di sistema (ad eccezione di init e shell domains) che violano il requisito di non eseguire binari del fornitore. L'esecuzione dei binari del fornitore ha un'API instabile. La piattaforma non deve eseguire direttamente i binari del fornitore. Consiglio:
  • Queste dipendenze della piattaforma dai binari del fornitore devono trovarsi dietro gli HAL HIDL.

    OPPURE

  • coredomains che devono accedere ai binari del fornitore devono essere spostati nella partizione vendor e quindi smettere di essere coredomain.

Attributi non attendibili

Le app non attendibili che ospitano codice arbitrario non devono avere accesso ai servizi HwBinder, ad eccezione di quelli considerati sufficientemente sicuri per l'accesso da parte di queste app (vedi i servizi sicuri di seguito). I due motivi principali sono:

1. I server HwBinder non eseguono l'autenticazione del client perché HIDL attualmente non espone le informazioni sull'UID del chiamante. Anche se HIDL esponesse questi dati, molti servizi HwBinder operano a un livello inferiore a quello delle app (ad esempio, HAL) o non devono fare affidamento sull'identità dell'app per l'autorizzazione. Pertanto, per sicurezza, l'ipotesi predefinita è che ogni servizio HwBinder tratti tutti i suoi client come ugualmente autorizzati a eseguire le operazioni offerte dal servizio.
2. I server HAL (un sottoinsieme di servizi HwBinder) contengono codice con un tasso di incidenza più elevato di problemi di sicurezza rispetto ai componenti system/core e hanno accesso ai livelli inferiori dello stack (fino all'hardware), aumentando così le opportunità di aggirare il modello di sicurezza di Android.

Servizi di casseforti

I servizi sicuri includono:

• same_process_hwservice. Questi servizi (per definizione) vengono eseguiti nel processo del client e pertanto hanno lo stesso accesso del dominio client in cui viene eseguito il processo.
• coredomain_hwservice. Questi servizi non comportano i rischi associati al motivo n. 2.
• hal_configstore_ISurfaceFlingerConfigs. Questo servizio è progettato specificamente per l'utilizzo da parte di qualsiasi dominio.
• hal_graphics_allocator_hwservice. Queste operazioni sono offerte anche dal servizio Binder surfaceflinger, a cui le app sono autorizzate ad accedere.
• hal_omx_hwservice. Si tratta di una versione HwBinder del servizio Binder mediacodec, a cui le app possono accedere.
• hal_codec2_hwservice. Questa è una versione più recente di hal_omx_hwservice.

Attributi utilizzabili

Tutti i hwservices non considerati sicuri hanno l'attributo untrusted_app_visible_hwservice. I server HAL corrispondenti hanno l'attributo untrusted_app_visible_halserver. I dispositivi lanciati con Android 9 NON DEVONO utilizzare l'attributo untrusted.

Consiglio:

• Le app non attendibili devono invece comunicare con un servizio di sistema che comunica con l'HAL HIDL del fornitore. Ad esempio, le app possono comunicare con binderservicedomain, poi mediaserver (che è un binderservicedomain) a sua volta comunica con hal_graphics_allocator.

  OPPURE

• Le app che richiedono l'accesso diretto agli HAL vendor devono avere il proprio dominio sepolicy definito dal fornitore.

Test degli attributi dei file

Android 9 include test in fase di compilazione che garantiscono che tutti i file in posizioni specifiche abbiano gli attributi appropriati (ad esempio, tutti i file in sysfs hanno l'attributo sysfs_type richiesto).

Etichettatura dei contesti SELinux

Per supportare la distinzione tra le norme SELinux della piattaforma e del fornitore, il sistema crea i file di contesto SELinux in modo diverso per mantenerli separati.

Contesti dei file

Android 8.0 ha introdotto le seguenti modifiche per file_contexts:

• Per evitare un sovraccarico di compilazione aggiuntivo sul dispositivo durante l'avvio, file_contexts non esisteranno più in formato binario. ma sono file di testo di espressioni regolari leggibili, come {property, service}_contexts (come nelle versioni precedenti alla 7.0).
• I file_contexts sono suddivisi in due file:
  • plat_file_contexts
    • Piattaforma Android file_context che non ha etichette specifiche del dispositivo, ad eccezione dell'etichettatura delle parti della partizione /vendor che deve essere etichettata con precisione per garantire il corretto funzionamento dei file sepolicy.
    • Deve risiedere nella partizione system in /system/etc/selinux/plat_file_contexts sul dispositivo ed essere caricato da init all'inizio insieme al file_context del fornitore.
  • vendor_file_contexts
    • file_context specifico del dispositivo creato combinando file_contexts trovato nelle directory indicate da BOARD_SEPOLICY_DIRS nei file Boardconfig.mk del dispositivo.
    • Deve essere installato in /vendor/etc/selinux/vendor_file_contexts nella partizione vendor e caricato da init all'inizio insieme alla piattaforma file_context.

Contesti della proprietà

In Android 8.0, il property_contexts è suddiviso in due file:

• plat_property_contexts
  • Piattaforma Android property_context che non ha etichette specifiche per dispositivo.
  • Deve risiedere nella partizione system in /system/etc/selinux/plat_property_contexts ed essere caricato da init all'inizio insieme al fornitore property_contexts.
• vendor_property_contexts
  • property_context specifico del dispositivo creato combinando property_contexts trovato nelle directory indicate da BOARD_SEPOLICY_DIRS nei file Boardconfig.mk del dispositivo.
  • Deve risiedere nella partizione vendor all'indirizzo /vendor/etc/selinux/vendor_property_contexts ed essere caricato da init all'inizio insieme alla piattaforma property_context

Contesti di servizio

In Android 8.0, service_contexts è suddiviso nei seguenti file:

• plat_service_contexts
  • service_context specifico per la piattaforma Android per servicemanager. service_context non ha etichette specifiche per il dispositivo.
  • Deve risiedere nella partizione system in /system/etc/selinux/plat_service_contexts ed essere caricato da servicemanager all'inizio insieme al fornitore service_contexts.
• vendor_service_contexts
  • service_context specifico del dispositivo creato combinando service_contexts trovato nelle directory indicate da BOARD_SEPOLICY_DIRS nei file Boardconfig.mk del dispositivo.
  • Deve risiedere nella partizione vendor in /vendor/etc/selinux/vendor_service_contexts ed essere caricato da servicemanager all'inizio insieme alla piattaforma service_contexts.
  • Sebbene servicemanager cerchi questo file al momento dell'avvio, per un dispositivo TREBLE completamente conforme, il vendor_service_contexts NON deve esistere. Questo perché tutta l'interazione tra vendor e system deve passare attraverso hwservicemanager/hwbinder.
• plat_hwservice_contexts
  • Piattaforma Android hwservice_context per hwservicemanager che non ha etichette specifiche per il dispositivo.
  • Deve risiedere nella partizione system in /system/etc/selinux/plat_hwservice_contexts ed essere caricato da hwservicemanager all'inizio insieme a vendor_hwservice_contexts.
• vendor_hwservice_contexts
  • hwservice_context specifico del dispositivo creato combinando hwservice_contexts trovato nelle directory indicate da BOARD_SEPOLICY_DIRS nei file Boardconfig.mk del dispositivo.
  • Deve risiedere nella partizione vendor in /vendor/etc/selinux/vendor_hwservice_contexts ed essere caricato da hwservicemanager all'inizio insieme a plat_service_contexts.
• vndservice_contexts
  • service_context specifico del dispositivo per vndservicemanager creato combinando vndservice_contexts trovati nelle directory indicate da BOARD_SEPOLICY_DIRS in Boardconfig.mk del dispositivo.
  • Questo file deve risiedere nella partizione vendor in /vendor/etc/selinux/vndservice_contexts ed essere caricato da vndservicemanager all'inizio.

Contesti seapp

In Android 8.0, il seapp_contexts è suddiviso in due file:

• plat_seapp_contexts
  • Piattaforma Android seapp_context senza modifiche specifiche per il dispositivo.
  • Deve risiedere nella partizione system in /system/etc/selinux/plat_seapp_contexts.
• vendor_seapp_contexts
  • Estensione specifica del dispositivo alla piattaforma seapp_context creata combinando seapp_contexts trovati nelle directory indicate da BOARD_SEPOLICY_DIRS nei file Boardconfig.mk del dispositivo.
  • Deve risiedere nella partizione vendor all'indirizzo /vendor/etc/selinux/vendor_seapp_contexts.

Autorizzazioni MAC

In Android 8.0, il mac_permissions.xml è suddiviso in due file:

• Piattaforma mac_permissions.xml
  • Piattaforma Android mac_permissions.xml senza modifiche specifiche del dispositivo.
  • Deve risiedere nella partizione system in /system/etc/selinux/.
• Non di piattaforma mac_permissions.xml
  • Estensione specifica del dispositivo alla piattaforma mac_permissions.xml creata da mac_permissions.xml trovata nelle directory indicate da BOARD_SEPOLICY_DIRS nei file Boardconfig.mk del dispositivo.
  • Deve risiedere nella partizione vendor in /vendor/etc/selinux/.