O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Fornecedor Init

O processo init tem permissões quase irrestritas e usa scripts de entrada do sistema e das partições do fornecedor para inicializar o sistema durante o processo de inicialização. Esse acesso causa uma grande falha na divisão sistema / fornecedor do Treble, pois os scripts do fornecedor podem instruir o init a acessar arquivos, propriedades, etc. que não fazem parte da interface binária do aplicativo do fornecedor do sistema estável (ABI).

O init do fornecedor é projetado para fechar essa lacuna usando um domínio separado do Linux com segurança avançada (SELinux) vendor_init para executar comandos encontrados em /vendor com permissões específicas do fornecedor.

Mecanismo

O init do fornecedor bifurca um subprocesso do init no início do processo de inicialização com o contexto SELinux u:r:vendor_init:s0 . Este contexto SELinux tem consideravelmente menos permissões que o contexto init padrão e seu acesso é restrito a arquivos, propriedades, etc. que são específicos do fornecedor ou parte da ABI do fornecedor do sistema estável.

O init verifica cada script que carrega para ver se seu caminho começa com /vendor e, em caso afirmativo, o marca com uma indicação de que seus comandos devem ser executados no contexto de init do fornecedor. Cada init integrado é anotado com um booleano que especifica se o comando deve ou não ser executado no subprocesso init do fornecedor:

  • A maioria dos comandos que acessam o sistema de arquivos são anotados para serem executados no subprocesso init do fornecedor e, portanto, estão sujeitos à SEPolicy init do fornecedor.
  • A maioria dos comandos que afetam o estado init interno (por exemplo, iniciando e interrompendo serviços) são executados dentro do processo init normal. Esses comandos são informados de que um script do fornecedor os está chamando para fazer seu próprio tratamento de permissões não SELinux.

O loop de processamento principal do init contém uma verificação de que se um comando é anotado para ser executado no subprocesso do fornecedor e se origina de um script do fornecedor, esse comando é enviado via comunicação entre processos (IPC) para o subprocesso init do fornecedor, que executa o comando e envia o resultado de volta para o init.

Usando o Fornecedor Init

O init do fornecedor é habilitado por padrão e suas restrições se aplicam a todos os scripts init presentes na partição /vendor . O init do fornecedor deve ser transparente para os fornecedores cujos scripts já não acessam somente arquivos do sistema, propriedades, etc.

No entanto, se os comandos em um determinado script de fornecedor violarem as restrições de inicialização do fornecedor, os comandos falharão. Comandos com falha têm uma linha no log do kernel (visível com dmesg) de init indicando falha. Uma auditoria SELinux acompanha qualquer comando com falha devido à política SELinux. Exemplo de uma falha incluindo uma auditoria 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 um comando falhar, existem duas opções:

  • Se o comando estiver falhando devido a uma restrição pretendida (por exemplo, se o comando estiver acessando um arquivo ou propriedade do sistema), o comando deve ser reimplementado de maneira amigável para o Treble, passando apenas por interfaces estáveis. As regras nunca permitidas impedem a adição de permissões para acessar arquivos do sistema que não fazem parte da ABI do fornecedor do sistema estável.
  • Se o rótulo SELinux for novo e ainda não tiver permissões concedidas no sistema vendor_init.te nem permissões excluídas por meio das regras neverallow, o novo rótulo pode receber permissões no vendor_init.te específico do dispositivo.

Para dispositivos lançados antes do Android 9, as regras neverallows podem ser contornadas adicionando o data_between_core_and_vendor_violators data_between_core_and_vendor_violators ao arquivo vendor_init.te específico do dispositivo.

Localizações de código

A maior parte da lógica para o IPC init do fornecedor está em system / core / init / subcontext.cpp .

A tabela de comandos está na classe BuiltinFunctionMap em system / core / init / builtins.cpp e inclui anotações que indicam se o comando deve ser executado no subprocesso init do fornecedor.

A SEPolicy para vendor init é dividida nosdiretórios private (system / sepolicy / private / vendor_init.te ) e público ( system / sepolicy / public / vendor_init.te ) em system / sepolicy.