Directory, regole e sepolicy

In questa pagina viene descritto il layout di directory per i dispositivi con Android 8.0 e delle regole VNDK e i rispettivi criteri di sicurezza associati.

Layout della directory

Il layout della directory degenerato è costituito da quanto segue directory:

• /system/lib[64] contiene tutte le librerie condivise del framework, tra cui LL-NDK, VNDK e librerie solo framework (tra cui LL-NDK-Private e alcune librerie con gli stessi nomi del quelli in VNDK-SP).
• /system/lib[64]/vndk-sp contiene librerie VNDK-SP per con gli HAL con lo stesso processo.
• /vendor/lib[64] contiene le librerie VNDK estese dal fornitore (sia librerie VNDK DXUA o DXUX), implementazioni HAL con lo stesso processo e altre implementazioni raccolte condivise.
• /vendor/lib[64]/vndk-sp potrebbe contenere le librerie VNDK-SP estese dal di terze parti.

I moduli del fornitore caricano le librerie VNDK da /system/lib[64].

Regole VNDK

Questa sezione fornisce un elenco completo delle regole VNDK:

• I processi framework non devono caricare librerie condivise non SP-HAL del fornitore partizioni di Compute Engine (applicato rigorosamente a partire da Android 8.1).
• I processi del fornitore non devono caricare file non LL-NDK, non VNDK-SP e delle librerie non VNDK dalla partizione di sistema. (non applicato rigorosamente in Android O, ma lo sarà in una versione futura).
• Le librerie VNDK installate devono essere un sottoinsieme di VNDK idonee definite da Google librerie.
• Le dipendenze esterne di SP-HAL e SP-HAL-Dep devono essere limitate a LL-NDK o librerie VNDK-SP definite da Google.
  • Le dipendenze di una libreria condivisa SP-HAL devono essere limitate a LL-NDK librerie, librerie VNDK-SP definite da Google, altre librerie SP-HAL e/o librerie condivise di altri fornitori etichettate come SP-HAL-Dep librerie.
  • Una libreria condivisa del fornitore può essere etichettata come libreria SP-HAL-Dep solo se non è una libreria AOSP e le sue dipendenze sono limitate alle librerie LL-NDK, Librerie VNDK-SP definite da Google, librerie SP-HAL e/o altre librerie SP-HAL-Dep librerie.
• VNDK-SP deve essere indipendente. libRS_internal.so diventa speciale in Android 8.0, ma verrà rivisto in una release futura.
• Nessuna comunicazione framework-fornitore tramite interfacce non HIDL, tra cui (a titolo esemplificativo) binder, socket, memorie condivise, file ecc.
• La dimensione della partizione di sistema deve essere abbastanza grande da contenere due copie di tutte le librerie VNDK idonee e una copia del framework non idoneo condiviso librerie.

Sepolicy

I processi framework descritti in questa sezione corrispondono coredomain nelle sepolicies, mentre i processi del fornitore corrispondono non-coredomain. Ad esempio, /dev/binder può essere è possibile accedere solo in coredomain e /dev/vndbinder a cui si accede solo in elementi diversi da coredomain.

Criteri simili limitano l'accesso alle librerie condivise sul sistema le partizioni del fornitore. La tabella seguente mostra i diritti di accesso librerie di diverse categorie:

LL-NDK-Private e VNDK-SP-Private devono essere accessibile da entrambi i domini perché gli utenti non coredomain accedervi indirettamente. Allo stesso modo, SP-HAL-Dep deve essere accessibile coredomain perché SP-HAL si basa su questo.

Etichetta stessa_processo_hal_file

Le seguenti librerie sono presenti nella partizione del fornitore. Rendi accessibili queste librerie da entrambi coredomain e non coredomain.

• VNDK-SP-Ext in /vendor/lib[64]/vndk-sp
• SP-HAL a /vendor/lib[64] o /vendor/lib[64]/hw
• SP-HAL-Dep a /vendor/lib[64] o /vendor/lib[64]/hw

Etichetta esplicitamente questi file come same_process_hal_file, perché qualsiasi cosa nella partizione vendor non è accessibile a coredomain. Aggiungi righe simili a quanto segue al file file_contexts specifico del fornitore.

/vendor/lib(64)?/hw/libMySpHal\.so        u:object_r:same_process_hal_file:s0
/vendor/lib(64)?/vndk-sp/libBase\.so      u:object_r:same_process_hal_file:s0
/vendor/lib(64)?/libBaseInternal\.so      u:object_r:same_process_hal_file:s0