Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Compatibilità delle politiche

Questo articolo descrive come Android gestisce i problemi di compatibilità dei criteri con gli OTA della piattaforma, in cui le impostazioni SELinux della nuova piattaforma possono differire dalle impostazioni SELinux del vecchio fornitore.

Il design della politica SELinux basata su alti considera una distinzione binaria tra la piattaforma e la politica del fornitore ; lo schema diventa più complicato se le partizioni del fornitore generano dipendenze, come la platform < vendor < oem .

In Android 8.0 e versioni successive, la politica globale di SELinux è divisa in componenti privati ​​e pubblici. I componenti pubblici sono costituiti dalla politica e dall'infrastruttura associata, garantiti per essere disponibili per una versione della piattaforma. Questa politica verrà esposta agli autori delle politiche del fornitore per consentire ai fornitori di creare un file delle politiche del fornitore che, se combinato con la politica fornita dalla piattaforma, si traduce in una politica completamente funzionale per un dispositivo.

  • Per il controllo delle versioni, la politica pubblica piattaforma esportata verrà scritta come attributi .
  • Per facilitare la scrittura delle politiche, i tipi esportati verranno trasformati in attributi con versione come parte del processo di creazione delle politiche. I tipi pubblici possono anche essere utilizzati direttamente nelle decisioni di etichettatura fornite dai file di contesti del fornitore.

Android mantiene una mappatura tra i tipi di calcestruzzo esportati nella politica della piattaforma e gli attributi di versione corrispondenti per ciascuna versione della piattaforma . Ciò garantisce che quando gli oggetti sono etichettati con un tipo, non interrompono il comportamento garantito dalla politica pubblica della piattaforma in una versione precedente. Questa mappatura viene mantenuta mantenendo un file di mappatura aggiornato per ogni versione della piattaforma , che mantiene le informazioni sull'appartenenza agli attributi per ciascun tipo esportato nella politica pubblica.

Proprietà dell'oggetto ed etichettatura

Quando si personalizzano i criteri in Android 8.0 e versioni successive, la proprietà deve essere chiaramente definita per ciascun oggetto per mantenere separati i criteri di piattaforma e fornitore. Ad esempio, se il fornitore etichetta /dev/foo e la piattaforma quindi etichetta /dev/foo in un OTA successivo, ci sarà un comportamento indefinito. Per SELinux, questo si manifesta come una collisione di etichettatura. Il nodo del dispositivo può avere una sola etichetta che si risolve nell'ultima etichetta applicata. Di conseguenza:

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

Le proprietà del sistema hanno anche il potenziale per nominare le collisioni che potrebbero comportare un comportamento indefinito sul sistema (così come per l'etichettatura SELinux). Le collisioni tra la piattaforma e le etichette del fornitore possono verificarsi per qualsiasi oggetto che abbia un'etichetta SELinux, incluse proprietà, servizi, processi, file e socket. Per evitare questi problemi, definire chiaramente la proprietà di questi oggetti.

Oltre alle collisioni di etichette, anche i nomi di tipo / attributo SELinux possono scontrarsi. Una collisione del nome di tipo / attributo comporterà sempre un errore del compilatore di criteri.

Tipo / attributo namespace

SELinux non consente più dichiarazioni dello stesso tipo / attributo. La politica con dichiarazioni duplicate non verrà compilata. Per evitare collisioni tra nomi e attributi, tutte le dichiarazioni dei fornitori devono essere np_ a partire da np_ .

type foo, domain; → type np_foo, domain;

Proprietà del sistema e proprietà dell'etichettatura del processo

Evitare le collisioni di etichettatura è meglio risolto utilizzando gli spazi dei nomi delle proprietà. Per identificare facilmente le proprietà della piattaforma ed evitare conflitti di nomi durante la ridenominazione o l'aggiunta di proprietà della piattaforma esportata, assicurarsi che tutte le proprietà del fornitore abbiano i propri prefissi:

Tipo di proprietà Prefissi accettabili
lettura scrivibile vendor.
sola lettura ro.vendor.
ro.boot.
ro.hardware.
persistente persist.vendor.

I fornitori possono continuare a utilizzare ro.boot.* (Che proviene dal cmdline del kernel) e ro.hardware.* (Un'ovvia proprietà relativa all'hardware).

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

Proprietà del file

Prevenire le collisioni per i file è una sfida poiché la politica di piattaforma e fornitore generalmente fornisce etichette per tutti i file system. A differenza della denominazione dei tipi, lo spazio dei nomi dei file non è pratico poiché molti di essi sono creati dal kernel. Per evitare queste collisioni, seguire la guida alla denominazione dei filesystem in questa sezione. Per Android 8.0, questi sono consigli senza applicazione tecnica. In futuro, queste raccomandazioni saranno applicate dalla Vendor Test Suite (VTS).

Sistema (/ sistema)

Solo l'immagine di sistema deve fornire etichette per /system componenti di /system tramite file_contexts , service_contexts , ecc. Se le etichette per /system componenti di /system vengono aggiunte nella politica /vendor , potrebbe non essere possibile un aggiornamento OTA solo per il framework.

Venditore (/ fornitore)

La politica SELOS di AOSP identifica già parti della partizione del vendor con cui la piattaforma interagisce, il che consente di scrivere regole SELinux per i processi della piattaforma per poter parlare e / o accedere a parti della partizione del vendor . Esempi:

/vendor percorso /vendor Etichetta fornita dalla piattaforma Processi della piattaforma a seconda dell'etichetta
/vendor(/. * )? vendor_file Tutti i client HAL in framework, ueventd , ecc.
/vendor/framework(/. * )? vendor_framework_file dex2oat , appdomain , ecc.
/vendor/app(/. * )? vendor_app_file dex2oat , installd , idmap , etc.
/vendor/overlay(/. * ) vendor_overlay_file system_server , zygote , idmap , ecc.

Di conseguenza, è necessario seguire regole specifiche (applicate attraverso neverallows ) quando si etichettano file aggiuntivi nella partizione del vendor :

  • vendor_file deve essere l'etichetta predefinita per tutti i file nella partizione del vendor . La politica della piattaforma richiede questo per accedere alle implementazioni HAL passthrough.
  • Tutti i nuovi exec_types aggiunti in vendor partizione attraverso vendor SEPolicy devono avere vendor_file_type attributo. Questo viene applicato attraverso neverallows.
  • Per evitare conflitti con futuri aggiornamenti di piattaforma / framework, evitare di etichettare file diversi da exec_types nella partizione del vendor .
  • Tutte le dipendenze delle librerie per gli HAL dello stesso processo identificati da AOSP devono essere etichettati come same_process_hal_file.

Procfs (/ proc)

I file in /proc possono essere etichettati usando solo l'etichetta genfscon . In Android 7.0, sia la piattaforma che la politica del fornitore utilizzavano genfscon per etichettare i file in procfs .

Raccomandazione: solo etichette /proc . Se i processi del vendor bisogno dell'accesso ai file in /proc che sono attualmente etichettati con l'etichetta predefinita ( proc ), la politica del fornitore non dovrebbe etichettarli esplicitamente e dovrebbe invece usare il tipo generico proc per aggiungere regole per i domini del fornitore. Ciò consente agli aggiornamenti della piattaforma di adattarsi alle future interfacce del kernel esposte tramite procfs e di etichettarle esplicitamente secondo necessità.

Debugfs (/ sys / kernel / debug)

Debugfs possono essere etichettati sia in file_contexts che in genfscon . In Android 7.0, debugfs sia per la piattaforma che per i distributori.

Raccomandazione: a breve termine, solo la politica del fornitore può etichettare i debugfs . A lungo termine, rimuovere debugfs .

Tracefs (/ sys / kernel / debug / tracing)

Tracefs possono essere etichettate in file_contexts e genfscon . In Android 7.0, solo la piattaforma identifica tracefs .

Raccomandazione: solo la piattaforma può etichettare tracefs .

Sysfs (/ sys)

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

Raccomandazione: la piattaforma può etichettare nodi sysfs che non sono specifici del dispositivo. Altrimenti, solo il fornitore può etichettare i file.

tmpfs (/ dev)

I file in /dev possono essere etichettati in file_contexts . In Android 7.0, sia i file di etichetta della piattaforma che quelli del fornitore qui.

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

Rootfs (/)

I file in / possono essere etichettati in file_contexts . In Android 7.0, sia i file di etichetta della piattaforma che quelli del fornitore qui.

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

Dati (/ dati)

I dati sono etichettati attraverso una combinazione di file_contexts e seapp_contexts .

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

Attributi di compatibilità

La politica di SELinux è un'interazione tra i tipi di origine e di destinazione per specifiche classi di oggetti e autorizzazioni. Ogni oggetto (processi, file, ecc.) Interessato dalla politica SELinux può avere un solo tipo, ma quel tipo può avere più attributi.

La politica è scritta principalmente in termini di tipi esistenti:

allow source_type target_type:target_class permission(s);

Questo funziona perché la politica è stata scritta con conoscenza di tutti i tipi. Tuttavia, se la politica del fornitore e la politica della piattaforma utilizzano tipi specifici e l'etichetta di un oggetto specifico cambia solo in una di tali politiche, l'altra può contenere una politica che ha ottenuto o perso l'accesso precedentemente invocato. Per esempio:

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

Potrebbe essere cambiato in:

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

Sebbene la politica del fornitore rimarrebbe la stessa, v_domain perderebbe l'accesso a causa della mancanza della politica per il nuovo tipo sysfs_A .

Definendo una politica in termini di attributi, possiamo assegnare all'oggetto sottostante un tipo che ha un attributo corrispondente alla politica sia per la piattaforma che per il codice fornitore. Questo può essere fatto per tutti i tipi per creare in modo efficace una politica di attributo in cui i tipi concreti non vengono mai utilizzati. In pratica, ciò è necessario solo per le parti della politica che si sovrappongono tra la piattaforma e il fornitore, che sono definite e fornite come politica pubblica della piattaforma che viene creata come parte della politica del fornitore.

La definizione delle politiche pubbliche come attributi con versione soddisfa due obiettivi di compatibilità delle politiche:

  • Assicurarsi che il codice fornitore continui a funzionare dopo l'aggiornamento della piattaforma . Ottenuto aggiungendo attributi a tipi concreti per oggetti corrispondenti a quelli su cui si basava il codice fornitore, preservando l'accesso.
  • Capacità di deprecare la politica . Raggiunto definendo chiaramente le serie di politiche in attributi che possono essere rimossi non appena la versione a cui corrispondono non è più supportata. Lo sviluppo può continuare nella piattaforma, sapendo che la vecchia politica è ancora presente nella politica del fornitore e verrà automaticamente rimossa quando / se si aggiorna.

Scrittura politica

Per raggiungere l'obiettivo di non richiedere la conoscenza di modifiche alla versione specifiche per lo sviluppo delle politiche, Android 8.0 include una mappatura tra i tipi di politiche pubblico-piattaforma e i loro attributi. Il tipo foo è associato all'attributo foo_v N , dove N è la versione scelta come destinazione. vN corrisponde alla variabile di build PLATFORM_SEPOLICY_VERSION ed è del formato MM.NN , dove MM corrisponde al numero SDK della piattaforma e NN è una versione specifica sepolicy della piattaforma.

Gli attributi nelle politiche pubbliche non sono sottoposti a versione, ma esistono piuttosto come API su cui possono essere sviluppate le politiche di piattaforma e fornitore per mantenere stabile l'interfaccia tra le due partizioni. Sia gli autori di policy di piattaforma che di fornitori possono continuare a scrivere policy come è scritto oggi.

Piattaforma pubblica politica esportata come allow source_foo target_bar: class perm ; è incluso come parte della politica del fornitore. Durante la compilazione (che include la versione corrispondente) viene trasformato nella politica che andrà alla parte del fornitore del dispositivo (mostrata nella Common Intermediate Language (CIL) trasformata):

 (allow source_foo_vN target_bar_vN (class (perm)))

Poiché la politica del fornitore non è mai in anticipo rispetto alla piattaforma, non dovrebbe interessare le versioni precedenti. Tuttavia, la politica della piattaforma dovrà sapere quanto è distante la politica del fornitore, includere gli attributi per i suoi tipi e impostare la politica corrispondente agli attributi con versione.

La politica differisce

La creazione automatica di attributi aggiungendo _v N alla fine di ogni tipo non fa nulla senza mappare gli attributi ai tipi attraverso le differenze di versione. Android mantiene una mappatura tra le versioni per gli attributi e una mappatura dei tipi su tali attributi. Questo viene fatto nei file di mapping summenzionati con istruzioni, come (CIL):

(typeattributeset foo_vN (foo))

Aggiornamenti della piattaforma

La seguente sezione descrive gli scenari per gli aggiornamenti della piattaforma.

Stessi tipi

Questo scenario si verifica quando un oggetto non modifica le etichette nelle versioni dei criteri. Questo è lo stesso per i tipi di origine e destinazione e può essere visto con /dev/binder , che è etichettato binder_device in tutte le versioni. È rappresentato nella politica trasformata come:

binder_device_v1 … binder_device_vN

Quando si esegue l'aggiornamento da v1v2 , la politica della piattaforma deve contenere:

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

Nella politica del fornitore v1 (CIL):

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

Nella politica del fornitore v2 (CIL):

(typeattribute binder_device_v2)
(allow binder_device_v2 …)
Nuovi tipi

Questo scenario si verifica quando la piattaforma ha aggiunto un nuovo tipo, cosa che può accadere quando si aggiungono nuove funzionalità o durante il rafforzamento dei criteri.

  • Nuova funzionalità . Quando il tipo sta etichettando un oggetto precedentemente inesistente (come un nuovo processo di servizio), il codice fornitore non ha interagito direttamente con esso in precedenza, quindi non esiste una politica corrispondente. Il nuovo attributo corrispondente al tipo non ha un attributo nella versione precedente e quindi non avrebbe bisogno di una voce nel file di mapping destinato a quella versione.
  • Indurimento delle politiche . Quando il tipo rappresenta la protezione avanzata, il nuovo attributo type deve ricollegarsi a una catena di attributi corrispondente alla precedente (simile all'esempio precedente che cambia /sys/A da sysfs a sysfs_A ). Il codice fornitore si basa su una regola che consente l'accesso a sysfs e deve includere tale regola come attributo del nuovo tipo.

Quando si esegue l'aggiornamento da v1v2 , la politica della piattaforma deve contenere:

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

Nella politica del fornitore v1 (CIL):

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Nella politica 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 viene rimosso un tipo, che può accadere quando l'oggetto sottostante:

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

Durante l'allentamento della politica, un tipo viene rimosso e all'oggetto etichettato con quel tipo viene assegnata un'etichetta diversa, già esistente. Ciò rappresenta una fusione di mappature degli attributi: il codice del fornitore deve essere ancora in grado di accedere all'oggetto sottostante dall'attributo che possedeva, ma il resto del sistema deve ora essere in grado di accedervi con il suo nuovo attributo.

Se l'attributo a cui è stato cambiato è nuovo, la rietichettatura è la stessa del caso del nuovo tipo, tranne per il fatto che quando viene utilizzata un'etichetta esistente, l'aggiunta del vecchio attributo nuovo tipo causerebbe altri oggetti etichettati con questo tipo essere di nuovo accessibile. Questo è essenzialmente ciò che viene fatto dalla piattaforma ed è considerato un compromesso accettabile per mantenere la compatibilità.

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

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

Quando si esegue l'aggiornamento da v1v2 , la politica della piattaforma deve contenere:

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

Nella politica del fornitore v1 (CIL):

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

Nella politica del fornitore v2 (CIL):

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

Esempio versione 2: rimozione completa (tipo foo)

Quando si esegue l'aggiornamento da v1v2 , la politica della piattaforma deve contenere:

# 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

Nella politica del fornitore v1 (CIL):

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

Nella politica del fornitore v2 (CIL):

(typeattribute sysfs_v2)
(allow sysfs_v2 …)
Nuova classe / permessi

Questo scenario si verifica quando un aggiornamento della piattaforma introduce nuovi componenti di criteri che non esistono nelle versioni precedenti. Ad esempio, quando Android ha aggiunto il gestore oggetti servicemanager che ha creato le autorizzazioni di aggiunta, ricerca ed elenco, i demoni del fornitore che desiderano registrarsi con il servicemanager necessitano di autorizzazioni non disponibili. In Android 8.0, solo i criteri della piattaforma possono aggiungere nuove classi e autorizzazioni.

Per consentire a tutti i domini che potrebbero essere stati creati o estesi dalla politica del fornitore di utilizzare la nuova classe senza ostacoli, la politica della piattaforma deve includere una regola simile a:

allow {domain -coredomain} *:new_class perm;

Ciò potrebbe anche richiedere una politica che consenta l'accesso per tutti i tipi di interfaccia (politica pubblica), per essere sicuro che l'immagine del fornitore ottenga l'accesso. Se ciò si traduce in una politica di sicurezza inaccettabile (come potrebbe accadere con le modifiche del gestore del servizio), un aggiornamento del fornitore potrebbe essere potenzialmente forzato.

Classe / autorizzazioni rimosse

Questo scenario si verifica quando un gestore oggetti viene rimosso (come il gestore oggetti ZygoteConnection ) e non dovrebbe causare problemi. La classe e le autorizzazioni del gestore oggetti potrebbero rimanere definite nella politica fino a quando la versione del fornitore non la utilizza più. Questo viene fatto aggiungendo 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 politiche dei fornitori in quanto sono necessari per descrivere nuovi processi, binari, dispositivi, sottosistemi e dati archiviati. Pertanto, è indispensabile consentire la creazione di tipi definiti dal fornitore.

Poiché la politica del fornitore è sempre la più vecchia sul dispositivo, non è necessario convertire automaticamente tutti i tipi di fornitore in attributi nella politica. La piattaforma non si basa su nulla etichettato nella politica del fornitore perché la piattaforma non ne è a conoscenza; tuttavia, la piattaforma fornirà gli attributi e i tipi pubblici che utilizza per interagire con oggetti etichettati con questi tipi (come domain , sysfs_type , ecc.). Affinché la piattaforma continui a interagire correttamente con questi oggetti, gli attributi e i tipi devono essere applicati in modo appropriato e potrebbe essere necessario aggiungere regole specifiche ai domini personalizzabili (come init ).

Modifiche agli attributi per Android 9

I dispositivi che eseguono l'aggiornamento ad Android 9 possono utilizzare i seguenti attributi, ma i dispositivi che si avviano con Android 9 non devono.

Attributi del violatore

Android 9 include questi attributi relativi 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 di piattaforma e fornitore non devono utilizzare file su disco per comunicare (ABI instabile). Raccomandazione:
    • Il codice fornitore deve utilizzare /data/vendor .
    • Il sistema non dovrebbe usare /data/vendor .
  • system_executes_vendor_violators . Attributo per tutti i domini di sistema (tranne i domini init e shell domains ) che violano il requisito di non eseguire i binari del fornitore. L'esecuzione dei file binari del fornitore ha un'API instabile. La piattaforma non dovrebbe eseguire direttamente i binari del fornitore. Raccomandazione:
    • Tali dipendenze della piattaforma dai file binari del fornitore devono essere alla base degli HAL HIDL.

      O

    • coredomains che necessitano dell'accesso ai file binari del fornitore devono essere spostate nella partizione del fornitore e, quindi, smettere di essere coredomain .

Attributi non attendibili

Le app non attendibili che ospitano codice arbitrario non dovrebbero avere accesso ai servizi HwBinder, ad eccezione di quelle considerate sufficientemente sicure per l'accesso da tali app (vedere i servizi sicuri di seguito). I due motivi principali per questo sono:

  1. I server HwBinder non eseguono l'autenticazione client poiché HIDL attualmente non espone le informazioni sull'UID del chiamante. Anche se HIDL ha rivelato tali dati, molti servizi di HwBinder operano a un livello inferiore a quello delle app (come HAL) o non devono fare affidamento sull'identità delle app per l'autorizzazione. Pertanto, per sicurezza, il presupposto predefinito è che ogni servizio HwBinder tratta tutti i suoi clienti come ugualmente autorizzati ad 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 di system/core e hanno accesso ai livelli inferiori dello stack (fino all'hardware) aumentando così le opportunità di bypassare il modello di sicurezza Android .

Servizi sicuri

I servizi sicuri includono:

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

Attributi utilizzabili

Tutti i servizi hwservices non considerati sicuri hanno l'attributo untrusted_app_visible_hwservice . I server HAL corrispondenti hanno l'attributo untrusted_app_visible_halserver . I dispositivi che si avviano con Android P NON DEVONO utilizzare alcun attributo untrusted .

Raccomandazione:

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

    O

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

Test degli attributi di file

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

Politica pubblica della piattaforma

La politica pubblica della piattaforma è il nucleo della conformità al modello di architettura Android 8.0 senza semplicemente mantenere l'unione delle politiche della piattaforma da v1 e v2. I fornitori sono esposti a un sottoinsieme di criteri di piattaforma che contiene tipi e attributi utilizzabili e regole su quei tipi e attributi che diventano quindi parte del criterio del fornitore (ovvero vendor_sepolicy.cil ).

I tipi e le regole vengono tradotti automaticamente nella politica generata dal fornitore in attribute_v N tale che tutti i tipi forniti dalla piattaforma siano attributi con versione (tuttavia gli attributi non sono con versione). La piattaforma è responsabile della mappatura dei tipi concreti che fornisce negli attributi appropriati per garantire che la politica del fornitore continui a funzionare e che siano incluse le regole fornite per una particolare versione. La combinazione di politica piattaforma-pubblico e politica del fornitore soddisfa l'obiettivo del modello di architettura Android 8.0 di consentire la creazione di piattaforme e fornitori indipendenti.

Mappatura su catene di attributi

Quando si utilizzano gli attributi per mappare le versioni delle politiche, un tipo si associa a un attributo o più attributi, garantendo che gli oggetti etichettati con il tipo siano accessibili tramite attributi corrispondenti ai loro tipi precedenti.

Mantenere un obiettivo per nascondere le informazioni sulla versione all'autore della politica significa generare automaticamente gli attributi con versione e assegnarli ai tipi appropriati. Nel caso comune di tipi statici, questo è semplice: type_foo mapping a type_foo_v1 .

Per una modifica dell'etichetta dell'oggetto come sysfssysfs_A o mediaserveraudioserver , la creazione di questa mappatura non è banale (ed è descritta negli esempi sopra). I manutentori della politica della piattaforma devono determinare come creare la mappatura nei punti di transizione per gli oggetti, il che richiede la comprensione della relazione tra gli oggetti e le loro etichette assegnate e la determinazione di quando ciò si verifica. Per compatibilità con le versioni precedenti, questa complessità deve essere gestita dal lato della piattaforma, che è l'unica partizione che può essere aggiornata.

Uprevs versione

Per semplicità, la piattaforma Android rilascia una versione sepolicy quando viene tagliato un nuovo ramo di rilascio. Come descritto sopra, il numero di versione è contenuto in PLATFORM_SEPOLICY_VERSION ed è nel formato MM.nn , dove MM corrisponde al valore SDK e nn è un valore privato mantenuto in /platform/system/sepolicy. 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 P. Uprevs non lo sono sempre numeri interi. Ad esempio, se un bump MR per una versione richiede una modifica incompatibile in system/sepolicy/public ma non un bump API, quella versione sepolicy potrebbe essere: vN.1 . La versione presente in un ramo di sviluppo è un dispositivo 10000.0 mai usato per la spedizione.

Android potrebbe deprecare la versione più vecchia quando si esegue il backup. Per informazioni su quando deprecare una versione, Android potrebbe raccogliere il numero di dispositivi con criteri del fornitore che eseguono quella versione di Android e continuano a ricevere importanti aggiornamenti della piattaforma. Se il numero è inferiore a una determinata soglia, tale versione è obsoleta.

Impatto sulle prestazioni di più attributi

Come descritto in https://github.com/SELinuxProject/cil/issues/9 , un gran numero di attributi assegnati a un tipo comporta problemi di prestazioni in caso di mancata memorizzazione nella cache dei criteri.

Ciò è stato confermato come un problema in Android, quindi sono state apportate modifiche ad Android 8.0 per rimuovere gli attributi aggiunti alla politica dal compilatore della politica, nonché per rimuovere gli attributi non utilizzati. Queste modifiche hanno risolto le regressioni delle prestazioni.

Etichettatura dei contesti SELinux

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

Contesti di file

Android 8.0 ha introdotto le seguenti modifiche per file_contexts :

  • Per evitare ulteriori sovraccarichi di compilazione sul dispositivo durante l'avvio, file_contexts cessa di esistere in forma binaria. Al contrario, sono file di testo di espressioni regolari leggibili come {property, service}_contexts (come erano pre-7.0).
  • I file_contexts sono divisi tra due file:
    • plat_file_contexts
      • Piattaforma Android file_context che non ha etichette specifiche del dispositivo, fatta eccezione per l'etichettatura di parti della partizione /vendor che devono essere etichettate con precisione per garantire il corretto funzionamento dei file sepolicy.
      • Deve risiedere nella partizione di 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 file_context creato combinando file_contexts trovati 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 del vendor ed essere caricato da init all'avvio insieme alla piattaforma file_context .

Contesti di proprietà

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

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

Contesti di servizio

In Android 8.0, service_contexts è suddiviso tra i seguenti file:

  • plat_service_contexts
    • service_context specifico per la piattaforma Android per il servicemanager . service_context non ha etichette specifiche del dispositivo.
    • Deve risiedere nel system partizione in /system/etc/selinux/plat_service_contexts ed essere caricato dal servicemanager al via insieme ai vendor service_contexts .
  • vendor_service_contexts
    • Dispositivo specifico service_context costruita combinando service_contexts trova nelle directory puntato da BOARD_SEPOLICY_DIRS in del dispositivo Boardconfig.mk file.
    • Deve risiedere in vendor partizione in /vendor/etc/selinux/vendor_service_contexts ed essere caricato dal servicemanager al via insieme con la piattaforma service_contexts .
    • Sebbene servicemanager vendor_service_contexts questo file all'avvio, per un dispositivo TREBLE pienamente conforme, il vendor_service_contexts NON DEVE esistere. Questo perché tutte le interazioni tra il vendor e i processi di system DEVONO passare attraverso hwservicemanager / hwbinder .
  • plat_hwservice_contexts
    • Piattaforma Android hwservice_context per hwservicemanager che non ha etichette specifiche del dispositivo.
    • Deve risiedere nella partizione di 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 hwservice_context creato combinando hwservice_contexts trovati nelle directory indicate da BOARD_SEPOLICY_DIRS nei file Boardconfig.mk del dispositivo.
    • Deve risiedere nella partizione del vendor in /vendor/etc/selinux/vendor_hwservice_contexts ed essere caricato da hwservicemanager all'inizio insieme a plat_service_contexts .
  • vndservice_contexts
    • Dispositivo-specifico service_context per la vndservicemanager costruito combinando vndservice_contexts trovato nelle directory puntato da BOARD_SEPOLICY_DIRS del dispositivo Boardconfig.mk .
    • Questo file deve risiedere nella partizione del vendor in /vendor/etc/selinux/vndservice_contexts ed essere caricato da vndservicemanager all'inizio.

Contesti Seapp

In Android 8.0, seapp_contexts è diviso tra due file:

  • plat_seapp_contexts
    • Piattaforma Android seapp_context che non ha modifiche specifiche del dispositivo.
    • Deve risiedere nella partizione di system in /system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • Estensione specifica del dispositivo per la 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 del vendor in /vendor/etc/selinux/vendor_seapp_contexts .

Autorizzazioni MAC

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

  • Piattaforma mac_permissions.xml
    • Piattaforma Android mac_permissions.xml che non presenta modifiche specifiche del dispositivo.
    • Deve risiedere nella partizione di system in /system/etc/selinux/.
  • mac_permissions.xml non di piattaforma
    • Estensione specifica del dispositivo per la 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 del vendor in /vendor/etc/selinux/.