Google is committed to advancing racial equity for Black communities. See how.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

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, até 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 do 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: tudo o que não for explicitamente permitido é negado. O SELinux pode operar em dois modos globais:

  • Modo permissivo , no qual 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 SELinux no modo de aplicação e uma política de segurança correspondente que funciona por padrão em 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á-los. Para obter mais detalhes, consulte Implementando SELinux .

O SELinux também oferece suporte a um modo permissivo por domínio no qual domínios (processos) específicos podem ser tornados permissivos enquanto o resto do sistema é colocado no modo de reforç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 execução).

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 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 de 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á em modo obrigatório no Android 5.xe superior.
  • Nenhum processo diferente de 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.

O Android 7.0 atualizou a configuração do SELinux para bloquear ainda mais a sandbox do aplicativo e reduzir a superfície de ataque. Esta versão também dividiu a pilha de mediaserver monolítica 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 Endurecendo 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 SELinux para permitir que os fabricantes de dispositivos e fornecedores SOC atualizem suas partes da política, construam suas imagens ( vendor.img , boot.img , etc.) e, em seguida, 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 do que a plataforma ( system.img ). Portanto, uma versão mais recente da plataforma 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 SELinux úteis, consulte os seguintes recursos: