Il processo di inizializzazione ha autorizzazioni quasi illimitate e utilizza gli script di input da le partizioni di sistema e del fornitore per inizializzare il sistema durante l'avvio e il processo di sviluppo. Questo accesso causa un enorme buco nella divisione tra sistema di Treble e fornitore, gli script del fornitore possono indicare init di accedere a file, proprietà e così via che non fanno parte dell'ABI (System-vendor Application binari Interface) stabile.
L'init del fornitore è progettato per chiudere questo foro utilizzando un file
dominio Linux (SELinux) con sicurezza avanzata vendor_init da eseguire
disponibili in /vendor con autorizzazioni specifiche del fornitore.
Meccanismo
L'init del fornitore crea un sottoprocesso di init all'inizio del processo di avvio con
Contesto SELinux u:r:vendor_init:s0. Questo contesto SELinux ha
un numero notevolmente inferiore di autorizzazioni rispetto al contesto init predefinito e il relativo accesso è
confinati a file, proprietà e così via che sono specifici del fornitore o
l'ABI stabile del fornitore del sistema.
Init controlla ogni script caricato per verificare se il percorso inizia con
/vendor e, in questo caso, la tagga con un'indicazione che i suoi comandi
devono essere eseguite nel contesto
init del fornitore. A ogni init integrato è annotata una
un valore booleano che specifica se il comando deve essere eseguito o meno nel campo init del fornitore
processo secondario:
- La maggior parte dei comandi che accedono al file system sono annotati per essere eseguiti nel fornitore init e sono quindi soggetti al criterio SEPolicy init del fornitore.
- La maggior parte dei comandi che hanno un impatto sullo stato di inizializzazione interno (ad es. avvio e arresto) vengono eseguite nel normale processo di inizializzazione. Questi comandi vengono creati sapendo che uno script del fornitore li chiama a eseguire una propria gestione delle autorizzazioni.
Il loop di elaborazione principale di init contiene un controllo che, se un comando è annotato nel processo secondario del fornitore e ha origine da uno script del fornitore, viene inviato tramite comunicazione tra processi (IPC) all'init che esegue il comando e invia il risultato a init.
Utilizzo di Vendor Init
L'init del fornitore è abilitato per impostazione predefinita e le sue limitazioni si applicano a tutti gli script di inizializzazione
presente nella partizione /vendor. L'init del fornitore deve essere trasparente
ai fornitori i cui script non accedono già ai file solo di sistema,
proprietà e così via.
Tuttavia, se i comandi di un determinato script del fornitore violano l'init del fornitore restrizioni, i comandi avranno esito negativo. I comandi con errori hanno una riga nel kernel log (visibile con dmesg) di init che indica un errore. Un controllo SELinux è accompagnato da qualsiasi comando non riuscito non riuscito a causa del criterio SELinux. Esempio di un errore che include un controllo SELinux:
type=1400 audit(1511821362.996:9): avc: denied { search } for pid=540 comm="init" name="nfc" dev="sda45" ino=1310721 scontext=u:r:vendor_init:s0 tcontext=u:object_r:nfc_data_file:s0 tclass=dir permissive=0
init: Command 'write /data/nfc/bad_file_access 1234' action=boot (/vendor/etc/init/hw/init.walleye.rc:422) took 2ms and failed: Unable to write to file '/data/nfc/bad_file_access': open() failed: Permission denied
In caso di errore di un comando, hai due opzioni:
- Se il comando non riesce a causa di una limitazione prevista (ad esempio, se accede a un file di sistema o a una proprietà), il comando deve essere reimplementati in modo da semplificare l'uso di Treble, passando solo attraverso interfacce stabili. Le regole di non consentire mai l'aggiunta di autorizzazioni per accedere a file di sistema che non sono parte dell'ABI stabile del fornitore del sistema.
- Se l'etichetta SELinux è nuova e non sono già state concesse autorizzazioni nella
il sistema
vendor_init.tené le autorizzazioni escluse tramite il di accesso rapido, alla nuova etichetta potrebbero essere concesse autorizzazionivendor_init.te.
Per i dispositivi che vengono lanciati prima di Android 9, le regole che non consentono mai possono essere aggirate
aggiungendo l'attributo di tipo data_between_core_and_vendor_violators a
il file vendor_init.te specifico del dispositivo.
Posizioni del codice
La maggior parte della logica per l'IPC init del fornitore si trova in system/core/init/subcontext.cpp.
La tabella dei comandi si trova nella classe BuiltinFunctionMap in system/core/init/builtins.cpp
e include annotazioni che indicano se il comando deve essere eseguito nel
init-subprocess.
Il SEPolicy per l'init del fornitore è suddiviso tra il privato (system/sepolicy/private/vendor_init.te) e pubblico (system/sepolicy/public/vendor_init.te) nel sistema/sepolicy.