O Google está comprometido em promover a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Inicial do fornecedor

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

O init do fornecedor foi projetado para fechar esse buraco usando um domínio vendor_init Linux (SELinux) com segurança aprimorada 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 . Esse contexto do SELinux possui consideravelmente menos permissões que o contexto inicial padrão e seu acesso é limitado a arquivos, propriedades etc. que são específicos do fornecedor ou fazem parte da ABI do fornecedor do sistema estável.

O Init verifica cada script carregado para ver se o caminho inicia com /vendor e, se for o caso, o identifica com uma indicação de que seus comandos devem ser executados no contexto init do fornecedor. Cada init embutido é 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 ao SEPolicy init do fornecedor.
  • A maioria dos comandos que impactam o estado inicial interno (por exemplo, iniciando e parando serviços) são executados dentro do processo normal de inicialização. Esses comandos são informados de que um script de fornecedor os está chamando para fazer seu próprio tratamento de permissões que não são do SELinux.

O loop principal de processamento 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 IPC (comunicação entre processos) para o subprocesso do fornecedor, que executa o comando e envia o resultado de volta ao init.

Usando a Inicialização do Fornecedor

O fornecedor init é ativado 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 fornecedores cujos scripts já não estão acessando apenas arquivos, propriedades do sistema 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. Os comandos com falha têm uma linha no log do kernel (visível com dmesg) do init indicando falha. Uma auditoria do SELinux acompanha qualquer comando com falha que falhou devido à política do SELinux. Exemplo de uma falha incluindo uma auditoria do 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, há duas opções:

  • Se o comando falhar devido a uma restrição pretendida (como se o comando estiver acessando um arquivo ou propriedade do sistema), o comando deverá ser reimplementado de uma maneira amigável ao Treble, passando apenas por interfaces estáveis. As regras Neverallow impedem a adição de permissões para acessar arquivos do sistema que não fazem parte da ABI estável do fornecedor do sistema.
  • 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 pelas regras de nunca permitir, o novo rótulo poderá receber permissões no vendor_init.te específico do dispositivo.

Para dispositivos de lançamento antes de Android 9, as regras neverallows pode ser contornado adicionando o data_between_core_and_vendor_violators typeattribute ao específico do dispositivo vendor_init.te arquivo.

Localizações do código

A maior parte da lógica do IPC de inicialização 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.

O SEPolicy para fornecedor init é dividido nos diretórios privado ( system / sepolicy / private / vendor_init.te ) e público ( system / sepolicy / public / vendor_init.te ) no system / sepolicy.