Linux com segurança aprimorada no Android

Como parte do modelo de segurança do Android , o Android usa o Security-Enhanced Linux (SELinux) para impor o controle de acesso obrigatório (MAC) em todos os processos, mesmo em 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 a dados de aplicativos e logs do sistema, reduzir os efeitos de softwares mal-intencionados 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ões 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 suporta um modo permissivo por domínio no qual domínios específicos (processos) podem se tornar permissivos enquanto o restante do sistema é colocado 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 seu próprio 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 sandbox 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 passou da aplicaçã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 imposição no Android 5.xe superior.
  • Nenhum processo além 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, redução da ameaça de serviços expostos, maior restrição de domínios SELinux e acesso /proc extremamente limitado.

O Android 7.0 atualizou a configuração do SELinux para bloquear ainda mais a área restrita do aplicativo e reduzir a superfície de ataque. Esta versão também dividiu a pilha monolítica de servidores de mídia 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 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 ( boot.img vendor.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 de plataforma mais recente pode apresentar problemas de compatibilidade do SELinux porque a política do 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 úteis do SELinux, consulte os seguintes recursos. Alguns conceitos do SELinux não são usados ​​pelo Android, veja a seção Especificidade ao considerar a documentação externa.