Linux com segurança aprimorada no Android

Como parte do modelo de segurança do Android, o Android usa Security-Enhanced Linux (SELinux) para impor o controle de acesso obrigatório (MAC) sobre todos os processos, mesmo processos executados com privilégios de root/superusuário (recursos do Linux). Muitas empresas e organizações contribuíram para a implementação do SELinux no Android. Com o SELinux, o Android pode proteger e confinar melhor os serviços do sistema, controlar o acesso aos dados de aplicativos e logs do sistema, reduzir os efeitos de software malicioso e proteger os usuários de possíveis falhas no código em dispositivos móveis.

O SELinux opera com base no princípio da negação padrão: qualquer coisa que não seja explicitamente permitida é negada. SELinux pode operar em dois modos globais:

  • Modo permissivo , no qual as negações de permissão são registradas, mas não aplicadas.
  • Modo de aplicação , no qual as negações de permissões são registradas e aplicadas.

O Android inclui o SELinux no modo de aplicação e uma política de segurança correspondente que funciona por padrão no AOSP. No modo de aplicação, as ações não permitidas são evitadas e todas as tentativas de violação são registradas pelo kernel em dmesg e logcat . Ao desenvolver, você deve usar esses erros para refinar seu software e as políticas do SELinux antes de aplicá-las. Para obter mais detalhes, consulte Implementando o SELinux .

O SELinux também suporta um modo permissivo por domínio no qual domínios específicos (processos) podem se tornar permissivos enquanto coloca o resto do sistema no modo de aplicação global. Um domínio é simplesmente um rótulo que identifica um processo ou conjunto de processos na política de segurança, onde todos os processos rotulados com o mesmo domínio são tratados de forma idêntica pela política de segurança. O modo permissivo por domínio permite a aplicação incremental do SELinux em uma parte cada vez maior do sistema e o desenvolvimento de políticas para novos serviços (enquanto mantém o restante do sistema em vigor).

Fundo

O modelo de segurança do Android é baseado em parte no conceito de sandboxes de aplicativos . Cada aplicativo é executado em sua própria sandbox. Antes do Android 4.3, esses sandboxes eram definidos pela criação de um UID Linux exclusivo para cada aplicativo no momento da instalação. O Android 4.3 e versões posteriores usam o SELinux para definir ainda mais os limites da sandbox do aplicativo Android.

No Android 5.0 e posterior, o SELinux é totalmente aplicado, com base no lançamento permissivo do Android 4.3 e na aplicação parcial do Android 4.4. Com essa mudança, o Android passou da aplicação de um conjunto limitado de domínios cruciais ( installd , netd , vold e zygote ) para tudo (mais de 60 domínios). Especificamente:

  • Tudo está em modo de aplicação no Android 5.xe superior.
  • Nenhum processo diferente do init deve ser executado no domínio init .
  • Qualquer negação genérica (para block_device , socket_device , default_service ) indica que o dispositivo precisa de um domínio especial.

O Android 6.0 fortaleceu o sistema, reduzindo a permissividade de nossa política para incluir melhor isolamento entre usuários, filtragem IOCTL, ameaça reduzida de serviços expostos, maior restrição de domínios SELinux e acesso /proc extremamente limitado.

Configuração SELinux atualizada do Android 7.0 para bloquear ainda mais a sandbox do aplicativo e reduzir a superfície de ataque. Esta versão também dividiu a pilha monolítica do mediaserver em processos menores para reduzir o escopo de suas permissões. Para obter mais detalhes, consulte Protegendo o Android com mais defesas do kernel Linux e Protegendo a pilha de mídia .

O Android 8.0 atualizou o SELinux para funcionar com Treble , que separa o código do fornecedor de nível inferior da estrutura do sistema Android. Esta versão atualizou a política SELinux para permitir que fabricantes de dispositivos e fornecedores de SOC atualizassem suas partes da política, construíssem suas imagens ( vendor.img , boot.img , etc.) e depois atualizassem essas imagens independentemente da plataforma ou vice-versa.

Embora seja possível ter uma versão de plataforma (estrutura) superior/mais recente em execução no dispositivo, o caso oposto não é suportado; as imagens do fornecedor ( vendor.img/odm.img ) não podem ter uma versão mais recente que a plataforma ( system.img ). Portanto, uma versão mais recente da plataforma pode apresentar problemas de compatibilidade do SELinux porque a política da plataforma SELinux está em uma versão mais recente do que as partes da política do fornecedor SELinux. O modelo Android 8.0 fornece um método para manter a compatibilidade e evitar OTAs simultâneos desnecessários.

Recursos adicionais

Para obter ajuda na construção de políticas SELinux úteis, consulte os recursos a seguir.