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

Venditore Init

Il processo di init 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 Treble del sistema / fornitore, poiché gli script del fornitore possono indicare a init di accedere a file, proprietà, ecc. Che non fanno parte dell'interfaccia binaria stabile (ABI) del sistema fornitore-sistema.

Vendor init è progettato per colmare questa lacuna utilizzando un dominio Linux (SELinux) separato per la sicurezza vendor_init per eseguire i comandi trovati in /vendor con autorizzazioni specifiche del fornitore.

Meccanismo

Il fornitore init avvia un sottoprocesso di init all'inizio del processo di avvio con il contesto SELinux u:r:vendor_init:s0 . Questo contesto SELinux ha molte meno autorizzazioni rispetto al contesto init predefinito e il suo accesso è limitato a file, proprietà, ecc. Che sono specifici del fornitore o fanno parte dell'ABI stabile del fornitore di sistema.

Init controlla ogni script caricato per vedere se il suo percorso inizia con /vendor e, in tal caso, lo contrassegna con un'indicazione che i suoi comandi devono essere eseguiti nel contesto di init del fornitore. Ogni builtin init è annotato con un valore booleano che specifica se il comando deve essere eseguito nel sottoprocesso init del fornitore:

  • La maggior parte dei comandi che accedono al file system sono annotati per essere eseguiti nel sottoprocesso di init del fornitore e sono quindi soggetti all'init di avvio SEPolicy.
  • La maggior parte dei comandi che influiscono sullo stato interno di init (ad esempio, l'avvio e l'arresto dei servizi) vengono eseguiti nel normale processo di init. Questi comandi vengono informati che uno script del fornitore li sta chiamando per eseguire la propria 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 proviene da uno script del fornitore, quel comando viene inviato tramite comunicazione tra processi (IPC) al sottoprocesso di avvio del fornitore, che esegue il comando e invia il risultato a init.

Utilizzando il fornitore Init

Vendor init è abilitato di default e le sue restrizioni si applicano a tutti gli script init presenti nella partizione /vendor . L'iniziatore del fornitore deve essere trasparente per i fornitori i cui script non stanno già accedendo solo ai file di sistema, alle proprietà, ecc.

Tuttavia, se i comandi in un determinato script del fornitore violano le restrizioni di avvio del fornitore, i comandi falliranno. I comandi non riusciti hanno una riga nel registro del kernel (visibile con dmesg) da init che indica l'errore. Un controllo SELinux accompagna qualsiasi comando non riuscito fallito a causa della politica SELinux. Esempio di errore incluso 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

Se un comando fallisce, ci sono due opzioni:

  • Se il comando non riesce a causa di una restrizione prevista (ad esempio se il comando sta accedendo a un file di sistema o a una proprietà), il comando deve essere implementato nuovamente in un modo adatto agli alti, passando solo attraverso interfacce stabili. Le regole di Neverallow impediscono l'aggiunta di autorizzazioni per accedere ai file di sistema che non fanno parte dell'ABI stabile del fornitore di sistema.
  • Se l'etichetta SELinux è nuova e non sono già state concesse autorizzazioni nel sistema vendor_init.te né autorizzazioni escluse tramite le regole neverallow, alla nuova etichetta possono essere concesse autorizzazioni nel vendor_init.te specifico del vendor_init.te .

Per i dispositivi che si avviano prima di Android 9, le regole di Neverallows possono essere ignorate aggiungendo i data_between_core_and_vendor_violators tipeattribute al file vendor_init.te specifico del dispositivo.

Posizioni del codice

La maggior parte della logica per il fornitore init IPC è in system / core / init / subcontext.cpp .

La tabella dei comandi è nella classe BuiltinFunctionMap in system / core / init / builtins.cpp e include le annotazioni che indicano se il comando deve essere eseguito nel sottoprocesso init del fornitore.

SEPolicy per vendor init è suddiviso tra le directory private ( system / sepolicy / private / vendor_init.te ) e public ( system / sepolicy / public / vendor_init.te ) in system / sepolicy.