Linux com segurança aprimorada no Android

Como parte do modelo de segurança do Android, o Android usa Security-Enhanced Linux (SELinux) para aplicar o controle de acesso obrigatório (MAC) em 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 do Android. Com o SELinux, o Android pode proteger e confinar melhor os serviços do sistema, controlar o acesso aos dados do aplicativo 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 de negação padrão: qualquer coisa que não seja explicitamente permitida é negada. O 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 imposição , no qual as negações de permissão são registradas e aplicadas.

O Android inclui o SELinux no modo de imposição e uma política de segurança correspondente que funciona por padrão no AOSP. No modo de imposiçã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á-los. Para obter mais detalhes, consulte Implementando o SELinux .

O SELinux também oferece suporte a um modo permissivo por domínio no qual domínios específicos (processos) podem se tornar permissivos enquanto coloca o restante do sistema no modo de imposiçã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 a 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 posterior usa o SELinux para definir ainda mais os limites da caixa de proteção do aplicativo Android.

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

  • Tudo está no modo de execução no Android 5.xe superior.
  • Nenhum processo diferente do init deve ser executado no domínio init .
  • Qualquer negação genérica (para um 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.

Android 7.0 atualizou a configuração do SELinux para bloquear ainda mais a caixa de proteção 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 do Linux e Fortalecendo a pilha de mídia .

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

Embora seja possível ter uma versão de plataforma (framework) 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 SELinux da plataforma está em uma versão mais recente do que as partes SELinux do fornecedor da política. O modelo Android 8.0 fornece um método para manter a compatibilidade para evitar OTAs simultâneos desnecessários.

Recursos adicionais

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