Compatibilità con i criteri

Questo articolo descrive in che modo Android gestisce i problemi di compatibilità delle norme con OTA sulla piattaforma, per le quali le nuove impostazioni SELinux sulla piattaforma possono differire da quelle del precedente fornitore Impostazioni SELinux.

La progettazione dei criteri SELinux basata su Treble prende in considerazione una distinzione binaria tra le norme relative alla piattaforma e al fornitore; lo schema diventa più complicata se le partizioni del fornitore generano dipendenze, ad esempio platform < vendor < oem.

In Android 8.0 e versioni successive, il criterio globale SELinux è suddiviso in private e componenti pubblici. I componenti pubblici sono costituiti dal criterio e dai relativi infrastruttura, la cui disponibilità è garantita per una versione della piattaforma. Questo criterio verrà esposto agli autori dei criteri dei fornitori per consentire ai fornitori di creare un file dei criteri dei fornitori che, se combinato con i criteri forniti dalla piattaforma, determina un criterio completamente funzionale per un dispositivo.

  • Per il controllo delle versioni, il criterio pubblico della piattaforma esportato verrà scritto come attributes.
  • Per semplificare la scrittura dei criteri, i tipi esportati verranno trasformati in attributi con versione come parte del processo di creazione del criterio. Pubblica possono essere usati direttamente nelle decisioni di etichettatura fornite dal fornitore di contesto.

Android mantiene una mappatura tra i tipi di cemento esportati nella piattaforma e i corrispondenti attributi sottoposti al controllo delle versioni per ciascuna piattaforma dell'audiodescrizione. In questo modo, quando gli oggetti sono etichettati con un tipo, non viola il comportamento garantito dal criterio platform-public in una versione precedente completamente gestita. Questa mappatura viene gestita mantenendo aggiornato un file di mappatura ogni versione della piattaforma, che conserva le informazioni sull'appartenenza agli attributi per tipo esportato nel criterio pubblico.

Proprietà ed etichettatura degli oggetti

Quando personalizzi le norme in Android 8.0 e versioni successive, la proprietà deve essere chiaramente definita per ogni oggetto, in modo da mantenere separati i criteri del fornitore e della piattaforma. Ad esempio, se le etichette del fornitore /dev/foo e la piattaforma etichetta quindi /dev/foo in una successiva OTA, ci sarà un comportamento indefinito. Per SELinux, si manifesta come una collisione di etichette. Il nodo dispositivo può avere solo una singola etichetta che si risolve nell'etichetta applicata per ultima. Ne consegue che:

  • I processi che richiedono l'accesso all'etichetta non applicata correttamente perdono l'accesso alla risorsa.
  • I processi che accedono l'accesso al file potrebbero non funzionare perché il nodo del dispositivo è stato creato.

Le proprietà del sistema possono anche causare collisioni di nomi che potrebbero comportare comportamento non definito sul sistema (così come per l'etichettatura SELinux). Collisioni tra le etichette della piattaforma e del fornitore è possibile per qualsiasi oggetto con un'interfaccia di etichette, inclusi proprietà, servizi, processi, file e socket. Da evitare definire chiaramente la proprietà di questi oggetti.

Oltre ai conflitti di etichette, potrebbero verificarsi conflitti tra i nomi di tipo/attributo di SELinux. Una collisione di tipo/attributo comporta sempre un errore del compilatore dei criteri.

Intervallo nomi per tipo/attributo

SELinux non consente più dichiarazioni dello stesso tipo/attributo. Norme con dichiarazioni duplicate non verranno compilate. Per evitare digitazione e dei nomi degli attributi, tutte le dichiarazioni del fornitore devono avere uno spazio dei nomi che inizia con vendor_. 

type foo, domain; → type vendor_foo, domain;

Proprietà di sistema e proprietà dell'etichettatura dei processi

La soluzione migliore per evitare le collisioni di etichette è utilizzare gli spazi dei nomi delle proprietà. A a identificare facilmente le proprietà della piattaforma ed evitare conflitti di nomi durante la ridenominazione l'aggiunta di proprietà della piattaforma esportata, assicura che tutte le proprietà del fornitore prefissi propri:

Tipo di struttura Prefissi accettabili
proprietà di controllo ctl.vendor.
ctl.start$vendor.
ctl.stop$vendor.
init.svc.vendor.
lettura in scrittura vendor.
sola lettura ro.vendor.
ro.boot.
ro.hardware.
persistente persist.vendor.

I fornitori possono continuare a utilizzare ro.boot.* (che proviene dal kernel) cmdline) e ro.hardware.* (una proprietà correlata all'hardware evidente).

Tutti i servizi dei fornitori nei file init rc devono avere vendor. per i servizi in file init rc di partizioni non di sistema. Regole simili sono applicata alle etichette SELinux per le proprietà del fornitore (vendor_ per le proprietà del fornitore).

Proprietà dei file

Evitare le collisioni dei file è difficile perché piattaforma e fornitore entrambi forniscono etichette per tutti i file system. A differenza della denominazione dei tipi, la spaziatura dei nomi dei file non è pratica perché molti di questi sono creati in un kernel. Per evitare queste collisioni, segui le indicazioni di denominazione per i file system in questa sezione. Per Android 8.0, questi sono consigli senza dati tecnici dell'applicazione delle norme. In futuro, questi consigli verranno applicati Suite di prova del fornitore (VTS).

Sistema (/system)

Solo l'immagine di sistema deve fornire le etichette per /system componenti tramite file_contexts, service_contexts e così via. Se le etichette per i componenti /system vengono aggiunti nel criterio /vendor, potrebbe non essere possibile aggiornare l'aggiornamento OTA solo del framework.

Fornitore (/fornitore)

Il criterio AOSP SELinux etichetta già parti della partizione vendor interagisce con la piattaforma, il che consente la scrittura di regole SELinux per processi per comunicare e/o accedere a parti di vendor della partizione di testo. Esempi:

/vendor percorso Etichetta fornita dalla piattaforma Processi della piattaforma in base all'etichetta
/vendor(/.*)? vendor_file Tutti i client HAL nel framework, ueventd e così via.
/vendor/framework(/.*)? vendor_framework_file dex2oat, appdomain e così via.
/vendor/app(/.*)? vendor_app_file dex2oat, installd, idmap e così via.
/vendor/overlay(/.*) vendor_overlay_file system_server, zygote, idmap e così via.

Di conseguenza, è necessario seguire regole specifiche (applicate neverallows) quando etichetti file aggiuntivi in vendor partizione:

  • vendor_file deve essere l'etichetta predefinita per tutti i file in vendor partizione. I criteri della piattaforma richiedono questa autorizzazione per accedere implementazioni HAL passthrough.
  • Tutti i nuovi exec_types aggiunti nella partizione vendor tramite SEPolicy del fornitore deve avere l'attributo vendor_file_type. Questo viene applicata tramite non consentire mai.
  • Per evitare conflitti con aggiornamenti futuri della piattaforma/del framework, evita di etichettare diversi da exec_types nella partizione vendor.
  • Tutte le dipendenze della libreria per gli HAL con lo stesso processo identificati da AOSP devono essere etichettato come same_process_hal_file.

Progetti (/proc)

I file in /proc possono essere etichettati utilizzando solo l'elemento genfscon dell'etichetta. In Android 7.0, e il fornitore criterio utilizzato genfscon per etichettare i file in procfs.

Consiglio: solo le etichette delle norme della piattaforma /proc. Se i processi vendor richiedono l'accesso a file in /proc che sono attualmente etichettati con l'etichetta predefinita (proc), "Vendor Policy" (Norme dei fornitori) non devono etichettarli esplicitamente, ma devono usare il modello proc per aggiungere regole per i domini dei fornitori. Ciò consente alla piattaforma per supportare le future interfacce del kernel esposte tramite procfs ed etichettale in modo esplicito in base alle esigenze.

Debugfs (/sys/kernel/debug)

Debugfs può essere etichettato sia in file_contexts che genfscon. Da Android 7.0 ad Android 10, piattaforma e etichetta del fornitore debugfs.

In Android 11, debugfs non può essere o montato su dispositivi di produzione. I produttori di dispositivi devono rimuovi debugfs.

Tracef (/sys/kernel/debug/tracciamento)

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

Consiglio: solo la piattaforma può etichettare tracefs.

Sistema (/sys)

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

Consiglio: la piattaforma potrebbe etichettare sysfs nodi non specifici per dispositivo. In caso contrario, solo il fornitore potrà etichettare i file.

tmpfs (/dev)

I file in /dev potrebbero essere etichettati in file_contexts. Nella Android 7.0, qui i file delle etichette del fornitore e della piattaforma.

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

Rootfs (/)

I file in / potrebbero essere etichettati in file_contexts. Su Android 7.0, qui puoi trovare i file delle etichette del fornitore e della piattaforma.

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 all'esterno /data/vendor. Solo la piattaforma può etichettare altre parti di /data.

Attributi di compatibilità

Il criterio SELinux è un'interazione tra i tipi di origine e di destinazione per specifici di oggetti Kubernetes e autorizzazioni. Tutti gli oggetti (processi, file e così via) interessati da SELinux può avere un solo tipo, ma questo tipo può avere più attributi.

Le norme sono scritte principalmente in termini di tipi esistenti: 

allow source_type target_type:target_class permission(s);

Funziona perché le norme sono state redatte con conoscenza di tutti i tipi. Tuttavia, se le norme per i fornitori e le norme relative alla piattaforma utilizzano tipi specifici e l'etichetta di un modifiche a un oggetto specifico solo in uno di questi criteri, l'altro può contenere che ha ottenuto o perso l'accesso su cui si basava in precedenza. Ad esempio: 

File_contexts:
/sys/A   u:object_r:sysfs:s0
Platform: allow p_domain sysfs:class perm;
Vendor: allow v_domain sysfs:class perm;

Può essere modificato in: 

File_contexts:
/sys/A   u:object_r:sysfs_A:s0

Anche se le norme per i fornitori rimarranno le stesse, il v_domain perderebbe l'accesso a causa della mancanza di criteri per il nuovo sysfs_A di testo.

Se definiamo un criterio in termini di attributi, possiamo dare all'oggetto sottostante con un attributo corrispondente al criterio sia per la piattaforma del fornitore. Ciò può essere fatto per tutti i tipi per creare in modo efficace un attribute-policy in cui non vengono mai utilizzati tipi concreti. In pratica, Questo è obbligatorio solo per le parti delle norme che si sovrappongono tra le piattaforme e del fornitore, che sono definiti e forniti come norme pubbliche della piattaforma creato nell'ambito dei criteri dei fornitori.

La definizione di criteri pubblici come attributi con controllo delle versioni soddisfa due criteri obiettivi di compatibilità:

  • Assicurati che il codice del fornitore continui a funzionare dopo l'aggiornamento della piattaforma. Si ottiene aggiungendo attributi ai tipi concreti per gli oggetti corrispondenti quelli su cui si basava il codice del fornitore, che mantengono l'accesso.
  • Possibilità di ritirare le norme. Raggiungibile in modo chiaro gli insiemi di criteri in attributi che possono essere rimossi non appena a cui corrispondono non è più supportata. Lo sviluppo può a continuare nella piattaforma, sapendo che la vecchia norma è ancora presente nella le norme del fornitore e verranno automaticamente rimosse quando/se viene eseguito l'upgrade.

Scrivibilità dei criteri

Per raggiungere l'obiettivo di non richiedere la conoscenza di specifiche modifiche alla versione per di sviluppo delle norme, Android 8.0 include una mappatura tipi di criteri e relativi attributi. Il tipo foo è mappato per attribuire foo_vN, dove N è il e la versione target. vN corrisponde alla PLATFORM_SEPOLICY_VERSION ed è in formato MM.NN, dove MM corrisponde al numero dell'SDK della piattaforma e NN è una versione specifica del sistema operativo della piattaforma.

Gli attributi nei criteri pubblici non vengono sottoposti al controllo delle versioni, ma esistono piuttosto come API quali criteri relativi a piattaforme e fornitori possono creare per mantenere l'interfaccia e la stabilità delle partizioni. Entrambi gli autori delle norme della piattaforma e dei fornitori possono continuare a scrivere come è scritto oggi.

Il criterio pubblico della piattaforma esportato come allow source_foo target_bar:class perm; è incluso nelle norme del fornitore. Durante compilation (che include versione corrispondente) viene trasformato nel criterio che verrà inviato del fornitore del dispositivo (mostrata nel pannello Common Intermediate trasformato Lingua (CIL): 

 (allow source_foo_vN target_bar_vN (class (perm)))

Poiché la politica dei fornitori non è mai in anticipo rispetto alla piattaforma, non dovrebbe preoccuparsi le versioni precedenti. Tuttavia, i criteri della piattaforma devono sapere quanto tempo fa il fornitore includere attributi ai rispettivi tipi e impostare il criterio corrispondente a con il controllo delle versioni.

Differenze criteri

Creazione automatica degli attributi aggiungendo _vN alla fine di ogni tipo non fa nulla senza la mappatura degli attributi ai tipi nella versione diverse. Android mantiene una mappatura tra le versioni per gli attributi e un una mappatura dei tipi a questi attributi. Ciò viene fatto con il mapping file con istruzioni, come (CIL): 

(typeattributeset foo_vN (foo))

Upgrade della piattaforma

La sezione seguente descrive in dettaglio gli scenari per gli upgrade della piattaforma.

Stessi tipi

Questo scenario si verifica quando un oggetto non modifica le etichette nelle versioni dei criteri. Lo stesso vale per i tipi di origine e di destinazione e può essere visualizzato con /dev/binder, che ha l'etichetta binder_device in tutti release. È rappresentato nei criteri trasformati come: 

binder_device_v1 … binder_device_vN

Quando esegui l'upgrade da v1 → v2, il criterio della piattaforma deve contiene: 

type binder_device; -> (type binder_device) (in CIL)

Nel file di mapping v1 (CIL): 

(typeattributeset binder_device_v1 (binder_device))

Nel file di mapping v2 (CIL): 

(typeattributeset binder_device_v2 (binder_device))

Nel criterio del fornitore v1 (CIL): 

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

Nel criterio del fornitore v2 (CIL): 

(typeattribute binder_device_v2)
(allow binder_device_v2 …)
Nuovi tipi

Questo scenario si verifica quando nella piattaforma viene aggiunto un nuovo tipo, che può verificarsi durante l'aggiunta di nuove funzionalità o durante la protezione avanzata dei criteri.

  • Nuova funzionalità. Quando il tipo etichetta un oggetto che era in precedenza inesistente (ad esempio, un nuovo processo di servizio), il codice del fornitore non che in precedenza interagiscono direttamente con quest'ultima, in modo che non esistano criteri corrispondenti. Il nuovo corrispondente al tipo non ha un attributo nella precedente e quindi non necessita di una voce nel targeting del file di mapping che completamente gestita.
  • Rafforzamento dei criteri. Quando il tipo rappresenta i criteri protezione avanzata, il nuovo attributo type deve rimandare a una catena di attributi corrispondente al precedente (simile all'esempio precedente che /sys/A dalle ore sysfs alle ore sysfs_A). Fornitore il codice si basa su una regola che consente l'accesso a sysfs e deve includerla come attributo del nuovo tipo.

Quando esegui l'upgrade da v1 → v2, il criterio della piattaforma deve contiene: 

type sysfs_A; -> (type sysfs_A) (in CIL)
type sysfs; (type sysfs) (in CIL)

Nel file di mapping v1 (CIL): 

(typeattributeset sysfs_v1 (sysfs sysfs_A))

Nel file di mapping v2 (CIL): 

(typeattributeset sysfs_v2 (sysfs))
(typeattributeset sysfs_A_v2 (sysfs_A))

Nel criterio del fornitore v1 (CIL): 

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Nel criterio del fornitore v2 (CIL): 

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)
Tipi rimossi

Questo (raro) scenario si verifica quando un tipo viene rimosso, cosa che può verificarsi quando oggetto sottostante:

  • Rimane, ma riceve un'etichetta diversa.
  • Viene rimosso dalla piattaforma.

Durante l'allentamento dei criteri, un tipo viene rimosso e l'oggetto viene etichettato con quel tipo ha un'etichetta diversa già esistente. Ciò rappresenta l'unione mappature degli attributi: il codice del fornitore deve poter comunque accedere all'elemento in base all'attributo che in precedenza possedeva, ma il resto del sistema ora deve potrà accedervi con il suo nuovo attributo.

Se l'attributo a cui è stato eseguito il passaggio è nuovo, la rietichettatura è come nel nuovo tipo di maiuscole e minuscole, tranne per il fatto che quando viene utilizzata un'etichetta esistente, aggiunta del vecchio attributo nuovo tipo provocherebbe che altri oggetti etichettati come di questo tipo per renderli accessibili di recente. Questo è essenzialmente ciò che viene fatto piattaforma ed è considerato un compromesso accettabile da mantenere la compatibilità. 

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Esempio di versione 1: tipi di compressione (rimozione di sysfs_A)

Quando esegui l'upgrade da v1 → v2, il criterio della piattaforma deve contiene: 

type sysfs; (type sysfs) (in CIL)

Nel file di mapping v1 (CIL): 

(typeattributeset sysfs_v1 (sysfs))
(type sysfs_A) # in case vendors used the sysfs_A label on objects
(typeattributeset sysfs_A_v1 (sysfs sysfs_A))

Nel file di mapping v2 (CIL): 

(typeattributeset sysfs_v2 (sysfs))

Nel criterio del fornitore v1 (CIL): 

(typeattribute sysfs_A_v1)
(allow … sysfs_A_v1 …)
(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Nel criterio del fornitore v2 (CIL): 

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

Versione di esempio 2: rimozione completa (tipo foo)

Quando esegui l'upgrade da v1 → v2, il criterio della piattaforma deve contiene: 

# nothing - we got rid of the type

Nel file di mapping v1 (CIL): 

(type foo) #needed in case vendors used the foo label on objects
(typeattributeset foo_v1 (foo))

Nel file di mapping v2 (CIL): 

# nothing - get rid of it

Nel criterio del fornitore v1 (CIL): 

(typeattribute foo_v1)
(allow foo …)
(typeattribute sysfs_v1)
(allow sysfs_v1 …)

Nel criterio del fornitore v2 (CIL): 

(typeattribute sysfs_v2)
(allow sysfs_v2 …)
Nuovo corso/autorizzazioni

Questo scenario si verifica quando un upgrade della piattaforma introduce nuovi componenti delle norme che non esistono nelle versioni precedenti. Ad esempio, quando Android ha aggiunto servicemanager gestore di oggetti che ha creato l'elemento di aggiunta, ricerca e elenco autorizzazioni, daemon dei fornitori che vogliono registrarsi servicemanager aveva bisogno di autorizzazioni che non erano disponibili. In Android 8.0, solo il criterio relativo alla piattaforma può aggiungere nuove classi e autorizzazioni aggiuntive.

Consentire tutti i domini che potrebbero essere stati creati o estesi in base alle norme del fornitore per utilizzare il nuovo corso senza ostacoli, i criteri della piattaforma devono includere un regola simile a: 

allow {domain -coredomain} *:new_class perm;

Questo può anche richiedere un criterio che consenta l'accesso a tutte le interfacce (criterio pubblico) per assicurarti che l'immagine del fornitore possa accedere. Se ciò risulta inaccettabile di sicurezza (come potrebbe avere con le modifiche servicemanager), un l'upgrade potrebbe essere forzato.

Corso/autorizzazioni rimossi

Questo scenario si verifica quando un gestore di oggetti viene rimosso (come il ZygoteConnection gestore di oggetti) e non deve causare problemi. La la classe e le autorizzazioni del gestore di oggetti potrebbero rimanere definite nel criterio della versione del fornitore non lo utilizza più. Per farlo, devi aggiungere le definizioni al file di mapping corrispondente.

Personalizzazione del fornitore per tipi nuovi/rietichettati

I nuovi tipi di fornitori sono al centro dello sviluppo delle norme dei fornitori in quanto sono necessari per descrivere nuovi processi, programmi binari, dispositivi, sottosistemi e dati memorizzati. Come per cui è imperativo consentire la creazione di tipi definiti dal fornitore.

Poiché i criteri dei fornitori sono sempre quelli meno recenti sul dispositivo, non è necessario convertire automaticamente tutti i tipi di fornitori in attributi nei criteri. La piattaforma non fa affidamento su elementi etichettati nelle norme dei fornitori perché la piattaforma non ha a conoscenza di questi aspetti; ma la piattaforma fornirà gli attributi e tipi che utilizza per interagire con oggetti etichettati con questi tipi (come domain, sysfs_type e così via). Affinché la piattaforma continuano a interagire correttamente con gli oggetti, gli attributi e i tipi devono essere applicate in modo appropriato e potrebbe essere necessario aggiungere regole specifiche domini personalizzabili (ad esempio init).

Modifiche agli attributi per Android 9

I dispositivi che eseguono l'upgrade ad Android 9 possono utilizzare i seguenti attributi, ma i dispositivi il lancio con Android 9 non deve.

Attributi del trasgressore

Android 9 include i seguenti attributi relativi al dominio:

  • data_between_core_and_vendor_violators Attributo per tutti i domini che violano il requisito di non condividere i file entro il percorso tra vendor e coredomains. Piattaforma e i processi del fornitore non dovrebbero utilizzare file su disco per comunicare (ABI instabile). Suggerimento:
    • Il codice fornitore deve utilizzare /data/vendor.
    • Il sistema non deve utilizzare /data/vendor.
  • system_executes_vendor_violators Attributo per tutti i domini di sistema (tranne init e shell domains) che violano il requisito di non eseguire i file binari dei fornitori. Esecuzione di i file binari dei fornitori hanno un'API instabile. La piattaforma non deve eseguire programmi binari dei fornitori strato Add. Suggerimento:
    • Tali dipendenze dalla piattaforma dai file binari dei fornitori devono essere protette da HAL HIDL.

      OPPURE

    • I file coredomains che richiedono l'accesso ai file binari dei fornitori devono essere spostati nella partizione del fornitore e, di conseguenza, non saranno più coredomain.

Attributi non attendibili

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

  1. I server HwBinder non eseguono l'autenticazione client perché attualmente HIDL non espone le informazioni dell'UID del chiamante. Anche se l'HIDL avesse esposto questi dati, molti I servizi HwBinder operano a un livello inferiore a quello delle app (ad esempio gli HAL) oppure non devono basarsi sull'identità dell'app per l'autorizzazione. Pertanto, per sicurezza, l'impostazione predefinita è che ogni servizio HwBinder tratti tutti i suoi clienti come autorizzate a eseguire operazioni offerte dal servizio.
  2. I server HAL (un sottoinsieme di servizi HwBinder) contengono codice con tasso di incidenza dei problemi di sicurezza rispetto a system/core componenti e ai livelli inferiori dello stack (fino all'hardware), quindi crescendo le opportunità di eludere il modello di sicurezza di Android.

Servizi di sicurezza

I servizi sicuri includono:

  • same_process_hwservice. Questi servizi (per definizione) vengono eseguiti al processo del client e, di conseguenza, hanno lo stesso accesso del dominio client eseguiti dal processo.
  • coredomain_hwservice. Questi servizi non comportano rischi associato al motivo n. 2.
  • hal_configstore_ISurfaceFlingerConfigs. Questo servizio è specificatamente progettati per l'uso da parte di qualsiasi dominio.
  • hal_graphics_allocator_hwservice. Anche queste operazioni offerte dal servizio Binder surfaceflinger, quali app sono consentite per accedere.
  • hal_omx_hwservice. Questa è una versione HwBinder della mediacodec Servizio Binder, a cui le app sono autorizzate ad 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. Lancio dei dispositivi con Android 9 NON DEVE utilizzare Attributo untrusted.

Consiglio:

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

    OPPURE

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

Test degli attributi del file

Android 9 include test del tempo di compilazione che verificano che tutti i file in specifiche posizioni hanno gli attributi appropriati (ad esempio, tutti i file in sysfs hanno l'attributo sysfs_type obbligatorio).

Criterio pubblico della piattaforma

La politica pubblica della piattaforma è il cuore della conformità ad Android 8.0 un modello di architettura senza limitarsi a mantenere l'unione dei criteri della piattaforma da v1 e v2. I fornitori sono esposti a un sottoinsieme di criteri della piattaforma che contiene tipi e attributi utilizzabili e regole su tali tipi e attributi che a quel punto diventa parte delle norme per i fornitori (ad es. vendor_sepolicy.cil).

Tipi e regole vengono tradotti automaticamente nelle norme generate dal fornitore in attribute_vN in modo che tutti i tipi forniti dalla piattaforma sono attributi con controllo delle versioni (tuttavia gli attributi non sono sottoposti al controllo delle versioni). La piattaforma responsabile di mappare i tipi di cemento che fornisce nei per garantire che i criteri dei fornitori continuino a funzionare e che le regole forniti per una determinata versione. La combinazione la politica pubblica della piattaforma e quella dei fornitori soddisfano l'architettura di Android 8.0 dell'obiettivo del modello di consentire la creazione di piattaforme e fornitori indipendenti.

Mappatura a catene di attributi

Quando utilizzi attributi per la mappatura alle versioni dei criteri, un tipo viene mappato a un attributo o più attributi, garantendo che gli oggetti etichettati con il tipo siano accessibili tramite corrispondenti ai tipi precedenti.

Mantenere l'obiettivo di nascondere le informazioni sulla versione al responsabile della scrittura delle norme significa generando automaticamente gli attributi sottoposti a controllo delle versioni e assegnandoli tipi appropriati. Nel caso comune dei tipi statici, questa procedura è semplice: type_foo mappa a type_foo_v1.

Per una modifica di un'etichetta di oggetto, ad esempio sysfs → sysfs_A o mediaserver → audioserver, la creazione di questa mappatura è non banali (ed è descritto negli esempi precedenti). Gestori dei criteri della piattaforma deve determinare come creare la mappatura nei punti di transizione degli oggetti, richiede la comprensione della relazione tra gli oggetti e etichette e determinare quando ciò si verifica. Per la compatibilità con le versioni precedenti, la complessità deve essere gestita sul lato della piattaforma, che è l'unica partizione che potrebbero aumentare le entrate.

Aggiornamenti delle versioni

Per semplicità, la piattaforma Android rilascia una versione Sepolicy quando viene il ramo di rilascio viene tagliato. Come descritto sopra, il numero di versione è contenuto in PLATFORM_SEPOLICY_VERSION, nel formato MM.nn, dove MM corrisponde al valore dell'SDK e nn è un valore privato mantenuto in /platform/system/sepolicy. Per ad esempio 19.0 per Kitkat, 21.0 per Lollipop, 22.0 per Lollipop-MR1 23.0 per Marshmallow, 24.0 per Nougat, 25.0 per Nougat-MR1, 26.0 per Oreo, 27.0 per Oreo-MR1 e 28.0 per Android 9. Gli incrementi non sono sempre numeri interi. Per Ad esempio, se un contatto MR a una versione richiede una modifica incompatibile system/sepolicy/public, ma non un contatto API, allora quel sepolicy potrebbe essere: vN.1. La versione presente in uno sviluppo ramo è un 10000.0 mai-to-essere-utilizzato-nei-dispositivi-di-spedizione.

Durante l'aggiornamento, Android potrebbe ritirare la versione meno recente. Per informazioni su quando ritirare una versione, Android potrebbe raccogliere il numero di dispositivi con il fornitore criteri che eseguono quella versione di Android e che continuano a ricevere le principali piattaforme aggiornamenti. Se il numero è inferiore a una certa soglia, la versione viene ritirato.

Impatto sulle prestazioni di più attributi

Come descritto in https://github.com/SELinuxProject/cil/issues/9, un elevato numero di attributi assegnati a un tipo causa problemi di prestazioni all'evento di un fallimento della cache dei criteri.

È stato confermato che si tratta di un problema di Android, pertanto le modifiche sono stati apportati ad Android 8.0 per rimuovere gli attributi aggiunti al criterio dal compilatore di criteri e per rimuovere gli attributi inutilizzati. Queste modifiche sono state risolte di regressione lineare delle prestazioni.

Norme pubbliche su System_ext e norme pubbliche del prodotto

A partire da Android 11, le partizioni system_ext e product sono autorizzate a i tipi pubblici designati nella partizione del fornitore. Metti Mi piace alla piattaforma pubbliche, il fornitore usa tipi e regole tradotti automaticamente in gli attributi sottoposti al controllo delle versioni, ad esempio da type a type_N, dove N è la versione della piattaforma su cui si basa la partizione del fornitore.

Quando le partizioni system_ext e product si basano sulla stessa versione della piattaforma N, il sistema di compilazione genera file di mapping di base su system_ext/etc/selinux/mapping/N.cil e product/etc/selinux/mapping/N.cil, che contengono l'identità mappature da type a type_N. Il fornitore può accedi a type con l'attributo Controllo delle versioni type_N.

Nel caso in cui vengano aggiornate solo le partizioni system_ext e product, diciamo Da N a N+1 (o versioni successive), mentre il fornitore rimane presso N, il fornitore potrebbe perdere l'accesso ai i tipi di system_ext e le partizioni product. Per evitare malfunzionamenti, system_ext e le partizioni di prodotto devono fornire file di mappatura da negli attributi type_N. Ogni partner responsabile della manutenzione dei file di mapping, se supporteranno Fornitore N con N+1 (o versioni successive) system_ext e product_ext.

A questo scopo, i partner sono tenuti a:

  1. Copia i file di mapping di base generati da N estensione di sistema e partizioni di prodotto all'albero di origine.
  2. Modifica i file di mappatura in base alle esigenze.
  3. Installa di mapping dei file a N+1 (o versioni successive) system_ext e partizioni di prodotto.

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

(typeattributeset foo_type_N (foo_type))
(expandtypeattribute foo_type_N true)
(typeattribute foo_type_N)

Se bar_type viene aggiunto a N+1 system_ext, e se bar_type deve essere mappato a foo_type per N fornitore, puoi aggiornare N.cil da 

(typeattributeset foo_type_N (foo_type))

a 

(typeattributeset foo_type_N (foo_type bar_type))

e quindi installato nella partizione di system_ext N+1. N fornitore può continuare ad accedere a N+1 foo_type e bar_type di system_ext.

Etichettatura dei contesti SELinux

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

Contesto dei file

Android 8.0 ha introdotto le seguenti modifiche per file_contexts:

  • Per evitare un ulteriore sovraccarico di compilazione sul dispositivo durante l'avvio, file_contexts non esiste più in formato binario. Invece, sono file di testo con espressioni regolari leggibili, come {property, service}_contexts (così come le versioni precedenti alla 7.0).
  • I file_contexts sono suddivisi tra due file:
    • plat_file_contexts
      • La piattaforma Android file_context che non ha specifiche per i dispositivi, ad eccezione dell'etichettatura di parti partizione /vendor che devono essere etichettate con precisione garantire il corretto funzionamento dei file sepolicy.
      • Deve trovarsi nella partizione system in /system/etc/selinux/plat_file_contexts sul dispositivo e verrà caricato da init all'inizio insieme il fornitore file_context.
    • vendor_file_contexts
      • file_context specifico per dispositivo creato combinando Trovato file_contexts nelle directory puntate da BOARD_SEPOLICY_DIRS nel Boardconfig.mk file.
      • Deve essere installata in /vendor/etc/selinux/vendor_file_contexts pollici partizione vendor e verrà caricata da init alle dall'inizio insieme alla piattaforma file_context.

Contesto della proprietà

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

  • plat_property_contexts
    • La piattaforma Android property_context che non ha specifiche per i dispositivi.
    • Deve trovarsi nella partizione system in /system/etc/selinux/plat_property_contexts e da caricare entro il giorno init all'inizio insieme al fornitore property_contexts.
  • vendor_property_contexts
    • property_context specifico per dispositivo creato combinando Trovato property_contexts nelle directory puntate da BOARD_SEPOLICY_DIRS nel dispositivo Boardconfig.mk file.
    • Deve trovarsi nella partizione vendor in /vendor/etc/selinux/vendor_property_contexts e sii caricato da init all'inizio insieme alla piattaforma property_context

Contesto dei servizi

In Android 8.0, service_contexts è suddiviso tra: file:

  • plat_service_contexts
    • service_context specifiche della piattaforma Android per il servicemanager. service_context non ha specifiche per i dispositivi.
    • Deve trovarsi nella partizione system in /system/etc/selinux/plat_service_contexts e verrà caricato da servicemanager all'inizio insieme al fornitore service_contexts.
  • vendor_service_contexts
    • service_context specifico per dispositivo creato combinando Trovato service_contexts nelle directory puntate da BOARD_SEPOLICY_DIRS nel Boardconfig.mk file.
    • Deve trovarsi nella partizione vendor in /vendor/etc/selinux/vendor_service_contexts e da caricare entro il giorno servicemanager all'inizio, insieme alla piattaforma service_contexts.
    • Anche se servicemanager cerca questo file al momento dell'avvio, per un dispositivo TREBLE completamente conforme, vendor_service_contexts NON DEVE esistere. Questo perché tutte le interazioni tra vendor e system processi DEVONO passare hwservicemanager/hwbinder.
  • plat_hwservice_contexts
    • Piattaforma Android hwservice_context per hwservicemanager senza etichette specifiche per il dispositivo.
    • Deve trovarsi nella partizione system in /system/etc/selinux/plat_hwservice_contexts e verrà caricato da hwservicemanager all'inizio insieme vendor_hwservice_contexts.
  • vendor_hwservice_contexts
    • hwservice_context specifico per dispositivo creato combinando Trovato hwservice_contexts nelle directory puntate da BOARD_SEPOLICY_DIRS nel Boardconfig.mk file.
    • Deve trovarsi nella partizione vendor in /vendor/etc/selinux/vendor_hwservice_contexts e sii caricato da hwservicemanager all'inizio insieme plat_service_contexts.
  • vndservice_contexts
    • service_context specifici del dispositivo per vndservicemanager creato combinando Trovato vndservice_contexts nelle directory puntate da BOARD_SEPOLICY_DIRS nel Boardconfig.mk.
    • Questo file deve trovarsi nella partizione vendor in /vendor/etc/selinux/vndservice_contexts e verrà caricato da vndservicemanager all'inizio.

Contesto SeApp

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

  • plat_seapp_contexts
    • Piattaforma Android seapp_context che non ha funzioni specifiche per il dispositivo modifiche.
    • Deve trovarsi nella partizione system in /system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • Estensione specifica per dispositivo alla piattaforma seapp_context creata combinando seapp_contexts presenti nelle directory indirizzato da BOARD_SEPOLICY_DIRS nel Boardconfig.mk file.
    • Deve trovarsi nella partizione vendor in /vendor/etc/selinux/vendor_seapp_contexts.

Autorizzazioni MAC

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

  • Piattaforma mac_permissions.xml
    • La piattaforma Android mac_permissions.xml che non ha modifiche specifiche per dispositivo.
    • Deve trovarsi nella partizione system in /system/etc/selinux/.
  • mac_permissions.xml (non piattaforma)
    • Estensione specifica per dispositivo alla piattaforma mac_permissions.xml creato da Trovato mac_permissions.xml nelle directory puntate da BOARD_SEPOLICY_DIRS nel Boardconfig.mk file.
    • Deve trovarsi nella partizione vendor in /vendor/etc/selinux/.