Como parte do modelo de segurança do Android, o sistema usa o Security-Enhanced Linux (SELinux) para aplicar o controle de acesso obrigatório (MAC) a todos os processos, mesmo aqueles em execução com privilégios de raiz/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 limitar melhor os serviços do sistema, controlar o acesso a dados de aplicativos e registros do sistema, reduzir os efeitos de softwares maliciosos e proteger os usuários contra possíveis falhas no código em dispositivos móveis.
O SELinux opera com base no princípio de negação padrão: tudo o que não é explicitamente permitido é negado. O SELinux pode operar em dois modos globais:
- Modo permissivo, em que as negações de permissão são registradas, mas não aplicadas.
- Modo de aplicação, em que as permissões negadas 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, ações
proibidas são impedidas e todas as tentativas de violação são registradas pelo kernel em
dmesg
e logcat
. Ao desenvolver, use
esses erros para refinar o software e as políticas do SELinux antes de aplicá-los. Para mais detalhes, consulte Como implementar
o SELinux.
O SELinux também oferece suporte a um modo permitido por domínio em que domínios específicos (processos) podem ser permitidos, enquanto o restante do sistema fica no modo de restrição global. Um domínio é simplesmente um rótulo que identifica um processo ou um conjunto de processos na política de segurança, em que todos os processos rotulados com o mesmo domínio são tratados de maneira 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 do desenvolvimento de políticas para novos serviços, mantendo a aplicação do restante do sistema.
Contexto
O modelo de segurança do Android é baseado em parte no conceito de sandboxes de aplicativos. Cada aplicativo é executado no próprio sandbox. Antes do Android 4.3, esses sandboxes eram definidos pela criação de um UID do Linux exclusivo para cada aplicativo no momento da instalação. O Android 4.3 e versões mais recentes usam o SELinux para definir melhor os limites do sandbox do aplicativo Android.
No Android 5.0 e versões mais recentes, 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 deixou de aplicar a restrição em um conjunto limitado de domínios
importantes (installd
, netd
, vold
e
zygote
) para todos (mais de 60 domínios). Especificamente:
- Tudo está no modo de ativação no Android 5.x e versões mais recentes.
- Nenhum processo além de
init
pode ser executado no domínioinit
. - Qualquer recusa genérica (para
block_device
,socket_device
,default_service
) indica que o dispositivo precisa de um domínio especial.
O Android 6.0 reforçou o sistema reduzindo a permissividade da nossa
política para incluir um melhor isolamento entre os 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 o sandbox do aplicativo e reduzir a superfície de ataque. Essa versão também dividiu a pilha monolítica do mediaserver em processos menores para reduzir o escopo das permissões. Para mais detalhes, consulte Proteger o Android com mais defesas do kernel do Linux e Aumento da proteção da 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 do framework do sistema Android. Essa versão atualizou a política do SELinux
para permitir que fabricantes de dispositivos e fornecedores de SOC atualizem partes
da política, criem imagens (vendor.img
, boot.img
etc.) e atualizem essas imagens independentemente da plataforma ou vice-versa.
Embora seja possível ter uma versão mais recente da plataforma (framework)
no dispositivo, o caso oposto não é aceito. As imagens do fornecedor
(vendor.img/odm.img
) não podem ter uma versão mais recente do que a plataforma
(system.img
). Portanto, uma versão mais recente da plataforma pode apresentar problemas de compatibilidade
com o SELinux porque a política do SELinux da plataforma está em uma versão mais recente
do que as partes do SELinux do fornecedor da política. O modelo do Android 8.0 oferece um método
para manter a compatibilidade e evitar
OTAs simultâneas desnecessárias.
Outros recursos
Para receber ajuda na criação de políticas úteis do SELinux, consulte os seguintes recursos.
- The SELinux Notebook: referência atualizada para o SELinux. Este documento contém mais detalhes sobre a linguagem da política, o significado de cada uma das palavras-chave e como os contextos de segurança são calculados.
- Seu guia de instruções visuais para a aplicação de políticas do SELinux
- Melhorias de segurança para Linux
- Android com segurança aprimorada (SE): trazendo o MAC flexível para o Android
- Como implementar o SELinux como um módulo de segurança do Linux
- Como configurar a política do SELinux