Il processo di inizializzazione ha autorizzazioni quasi illimitate e utilizza script di input sia dal sistema che dalle partizioni del fornitore per inizializzare il sistema durante il processo di avvio. Questo accesso provoca un enorme buco nella divisione sistema/fornitore di Treble, poiché gli script del fornitore possono istruire init ad accedere a file, proprietà, ecc. che non fanno parte dell'interfaccia binaria dell'applicazione (ABI) stabile del fornitore del sistema.
Vendor init è progettato per chiudere questo buco utilizzando un dominio Linux (SELinux) separato con sicurezza avanzata vendor_init per eseguire i comandi trovati in /vendor con autorizzazioni specifiche del fornitore.
Meccanismo
L'init del fornitore esegue il fork di un sottoprocesso di init all'inizio del processo di avvio con il contesto SELinux u:r:vendor_init:s0 . Questo contesto SELinux ha permessi considerevolmente inferiori rispetto al contesto init predefinito e il suo accesso è limitato a file, proprietà, ecc. Che sono specifici del fornitore o parte dell'ABI stabile del fornitore del sistema.
Init controlla ogni script che carica per vedere se il suo percorso inizia con /vendor e, in tal caso, lo tagga con l'indicazione che i suoi comandi devono essere eseguiti nel contesto init del fornitore. Ogni built-in init è annotato con un valore booleano che specifica se il comando deve essere eseguito o meno nel sottoprocesso init del fornitore:
- La maggior parte dei comandi che accedono al file system sono annotati per essere eseguiti nel sottoprocesso init del fornitore e sono pertanto soggetti alla SEPolicy init del fornitore.
- La maggior parte dei comandi che influiscono sullo stato di inizializzazione interno (ad esempio, l'avvio e l'arresto dei servizi) vengono eseguiti all'interno del normale processo di inizializzazione. Questi comandi vengono informati del fatto che uno script del fornitore li chiama per eseguire la gestione delle autorizzazioni non SELinux.
Il ciclo di elaborazione principale di init contiene un controllo che se un comando è annotato per essere eseguito nel sottoprocesso del fornitore e ha origine da uno script del fornitore, tale comando viene inviato tramite comunicazione interprocesso (IPC) al sottoprocesso init del fornitore, che esegue il comando e invia il risultato a init.
Utilizzando il fornitore Init
L'init del fornitore è abilitato per impostazione predefinita e le sue restrizioni si applicano a tutti gli script di init presenti nella partizione /vendor . L'init del fornitore dovrebbe essere trasparente per i fornitori i cui script non accedono già solo a file, proprietà, ecc. del sistema.
Tuttavia, se i comandi in un determinato script del fornitore violano le restrizioni di inizializzazione del fornitore, i comandi falliranno. I comandi che falliscono hanno una riga nel log del kernel (visibile con dmesg) da init che indica il fallimento. Un controllo SELinux accompagna qualsiasi comando fallito a causa della politica SELinux. Esempio di errore che include un audit 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 deniedSe un comando fallisce, ci sono due opzioni:
- Se il comando non funziona a causa di una restrizione prevista (ad esempio se il comando accede a un file di sistema o a una proprietà), il comando deve essere reimplementato in modo Treble-friendly, passando solo attraverso interfacce stabili. Le regole Neverallow impediscono di aggiungere autorizzazioni per accedere ai file di sistema che non fanno parte dell'ABI stabile del fornitore del sistema.
- Se l'etichetta SELinux è nuova e non sono già concesse autorizzazioni nel sistema
vendor_init.tené autorizzazioni escluse tramite le regole neverallow, alla nuova etichetta potrebbero essere concesse autorizzazioni nelvendor_init.tespecifico del dispositivo.
Per i dispositivi avviati prima di Android 9, le regole neverallows possono essere aggirate aggiungendo l'attributo data_between_core_and_vendor_violators al file vendor_init.te specifico del dispositivo.
Posizioni dei codici
La maggior parte della logica per l'IPC init del fornitore è 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 sottoprocesso init del fornitore.
La SEPolicy per l'init del fornitore è suddivisa tra le directory privata ( system/sepolicy/private/vendor_init.te ) e pubblica ( system/sepolicy/public/vendor_init.te ) in system/sepolicy.