Implementar a segurança

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

A equipe de segurança do Android recebe regularmente solicitações de informações sobre como evitar possíveis problemas de segurança em dispositivos Android. Também fazemos verificações pontuais de dispositivos e informamos os fabricantes e parceiros afetados sobre possíveis problemas.

Esta página oferece práticas recomendadas de segurança com base nas nossas experiências, ampliando a documentação Designing for Security que fornecemos para desenvolvedores e inclui detalhes exclusivos para criar ou instalar softwares no nível do sistema em dispositivos.

Para facilitar a adoção dessas práticas recomendadas, sempre que possível, a equipe de segurança do Android incorpora testes ao Conjunto de teste de compatibilidade do Android (CTS) e ao Android Lint. Recomendamos que os implementadores de dispositivos contribuam com testes que possam ajudar outros usuários do Android. Confira os testes relacionados à segurança em root/cts/tests/tests/security/src/android/security/cts.

Processo de desenvolvimento

Use as práticas recomendadas a seguir nos seus processos e ambientes de desenvolvimento.

Revisar o código-fonte

A análise do código-fonte pode detectar uma ampla gama de problemas de segurança, incluindo aqueles identificados neste documento. O Android incentiva a revisão manual e automática do código-fonte. Práticas recomendadas

• Execute o Android Lint em todo código do app usando o SDK do Android e corrija os problemas identificados.
• O código nativo precisa ser analisado usando uma ferramenta automatizada que possa detectar problemas de gerenciamento de memória, como estouro de buffer e erros de um.
• O sistema de build do Android oferece suporte a muitos dos limpadores LLVM, como AddressSanitizer e UndefinedBehaviorSanitizer, que podem ser usados para esse fim.

Usar testes automatizados

Os testes automatizados podem detectar uma ampla gama de problemas de segurança, incluindo vários problemas discutidos abaixo. Práticas recomendadas

• O CTS é atualizado regularmente com testes de segurança. Execute a versão mais recente do CTS para verificar a compatibilidade.
• Execute o CTS regularmente durante o processo de desenvolvimento para detectar problemas antecipadamente e reduzir o tempo de correção. O Android usa o CTS como parte da integração contínua no nosso processo de build automatizado, que é executado várias vezes por dia.
• Os fabricantes de dispositivos precisam automatizar os testes de segurança das interfaces, incluindo testes com entradas incorretas (testes de fuzz).

Assinar imagens do sistema

A assinatura da imagem do sistema é essencial para determinar a integridade do dispositivo. Práticas recomendadas

• Os dispositivos não podem ser assinados com uma chave conhecida publicamente.
• As chaves usadas para assinar dispositivos precisam ser gerenciadas de acordo com as práticas padrão do setor para lidar com chaves sensíveis, incluindo um módulo de segurança de hardware (HSM) que ofereça acesso limitado e auditável.

Assinar apps (APKs)

As assinaturas de apps têm um papel importante na segurança do dispositivo e são usadas para verificações de permissões e atualizações de software. Ao selecionar uma chave para assinar apps, é importante considerar se um app vai estar disponível apenas em um único dispositivo ou se será comum em vários dispositivos. Práticas recomendadas

• Os apps não podem ser assinados com uma chave conhecida publicamente.
• As chaves usadas para assinar apps precisam ser gerenciadas de maneira consistente com as práticas padrão do setor para lidar com chaves sensíveis, incluindo um HSM que ofereça acesso limitado e auditável.
• Os apps não podem ser assinados com a chave da plataforma.
• Apps com o mesmo nome de pacote não podem ser assinados com chaves diferentes. Isso geralmente ocorre ao criar um app para diferentes dispositivos, especialmente ao usar a chave da plataforma. Se o app não for independente do dispositivo, use a mesma chave em todos os dispositivos. Se o app for específico para o dispositivo, crie nomes de pacotes exclusivos por dispositivo e chave.

Publicar apps

O Google Play permite que os fabricantes de dispositivos atualizem apps sem realizar uma atualização completa do sistema. Isso pode acelerar a resposta a problemas de segurança e o envio de novos recursos, além de oferecer uma maneira de garantir que o app tenha um nome de pacote exclusivo. Práticas recomendadas

• Faça upload dos seus apps no Google Play para permitir atualizações automáticas sem exigir uma atualização completa over the air (OTA). Os apps que são enviados mas não publicados não podem ser baixados diretamente pelos usuários, mas ainda são atualizados. Os usuários que já instalaram o app podem reinstalar e/ou instalar em outros dispositivos.
• Crie um nome de pacote de app claramente associado à sua empresa, como usando uma marca registrada.
• Os apps publicados por fabricantes de dispositivos precisam ser enviados para a loja do Google Play para evitar a falsificação de nome de pacote por usuários de terceiros. Se um fabricante de dispositivos instalar um app em um dispositivo sem publicá-lo na Play Store, outro desenvolvedor poderá fazer upload do mesmo app, usar o mesmo nome de pacote e mudar os metadados dele. Quando o app é apresentado ao usuário, esses metadados não relacionados podem causar confusão.

Responder a incidentes

Partes externas precisam ter a capacidade de entrar em contato com os fabricantes de dispositivos sobre problemas de segurança específicos do dispositivo. Recomendamos criar um endereço de e-mail acessível publicamente para gerenciar incidentes de segurança. Práticas recomendadas

• Crie um endereço security@suaempresa.com ou semelhante e divulgue-o.
• Se você souber de um problema de segurança que afeta o SO Android ou dispositivos Android de vários fabricantes, entre em contato com a equipe de segurança do Android enviando um relatório de bug de segurança.

Implementar produtos

Use as práticas recomendadas a seguir ao implementar um produto.

Isolar processos raiz

Os processos raiz são o alvo mais frequente de ataques de elevação de privilégios. Portanto, reduzir o número de processos raiz reduz o risco de elevação de privilégios. O CTS inclui um teste informativo que lista os processos raiz. Práticas recomendadas

• Os dispositivos precisam executar o código mínimo necessário como raiz. Sempre que possível, use um processo normal do Android em vez de um processo raiz. O Galaxy Nexus do ICS tem apenas seis processos raiz: vold, inetd, zygote, tf_daemon, ueventd e init. Se um processo precisar ser executado como raiz em um dispositivo, documente o processo em uma solicitação de recurso do AOSP para que ele possa ser analisado publicamente.
• Sempre que possível, o código raiz precisa ser isolado de dados não confiáveis e acessado pelo IPC. Por exemplo, reduza a funcionalidade raiz a um pequeno serviço acessível pelo Binder e exponha o serviço com permissão de assinatura a um app com poucos ou nenhum privilégio para processar o tráfego de rede.
• Os processos raiz não podem detectar um socket de rede.
• Os processos raiz não podem fornecer um ambiente de execução de uso geral para apps (por exemplo, uma VM Java).

Isolar apps do sistema

Em geral, os apps pré-instalados não são executados com o UID do sistema compartilhado. No entanto, se for necessário que um app use o UID compartilhado do sistema ou de outro serviço privilegiado, ele não poderá exportar serviços, broadcast receivers ou provedores de conteúdo que possam ser acessados por apps de terceiros instalados pelos usuários. Práticas recomendadas

• Os dispositivos precisam executar o código mínimo necessário como sistema. Sempre que possível, use um processo do Android com o próprio UID em vez de reutilizar o UID do sistema.
• Sempre que possível, o código do sistema precisa ser isolado de dados não confiáveis e expor o IPC apenas para outros processos confiáveis.
• Os processos do sistema não podem detectar um soquete de rede.

Isolar processos

O sandbox de apps Android oferece aos apps uma expectativa de isolamento de outros processos no sistema, incluindo processos raiz e depuradores. A menos que a depuração seja especificamente ativada pelo app e pelo usuário, nenhum app pode violar essa expectativa. Práticas recomendadas

• Os processos raiz não podem acessar dados em pastas de dados de apps individuais, a menos que usem um método de depuração do Android documentado.
• Os processos raiz não podem acessar a memória de apps, a menos que usem um método de depuração do Android documentado.
• Os dispositivos não podem incluir nenhum app que acesse dados ou memória de outros apps ou processos.

Proteger arquivos SUID

Os novos programas setuid não podem ser acessados por programas não confiáveis. Os programas setuid muitas vezes são o local de vulnerabilidades que podem ser usadas para conseguir acesso raiz. Portanto, tente minimizar a disponibilidade do programa setuid para apps não confiáveis. Práticas recomendadas

• Os processos SUID não podem fornecer um shell ou backdoor que possa ser usado para contornar o modelo de segurança do Android.
• Os programas SUID não podem ser graváveis por nenhum usuário.
• Os programas SUID não podem ser legíveis ou executáveis para todos. Crie um grupo, limite o acesso ao binário SUID para membros desse grupo e coloque todos os apps que precisam executar o programa SUID nesse grupo.
• Os programas SUID são uma fonte comum de acesso root por usuários. Para reduzir esse risco, os programas SUID não podem ser executáveis pelo usuário do shell.

O verificador do CTS inclui um teste informativo que lista arquivos SUID. Alguns arquivos setuid não são permitidos nos testes do CTS.

Sockets de escuta seguros

Os testes de CTS falham quando um dispositivo está a ouvir em qualquer porta, em qualquer interface. Em caso de falha, o Android verifica se as seguintes práticas recomendadas estão em uso:

• Não deve haver portas de escuta no dispositivo.
• As portas de detecção precisam poder ser desativadas sem uma OTA. Isso pode ser uma mudança de configuração do servidor ou do dispositivo do usuário.
• Os processos raiz não podem detectar nenhuma porta.
• Os processos pertencentes ao UID do sistema não podem detectar nenhuma porta.
• Para IPC local usando soquetes, os apps precisam usar um soquete de domínio UNIX com acesso limitado a um grupo. Crie um descritor de arquivo para o IPC e torne-o +RW para um grupo UNIX específico. Todos os apps clientes precisam estar nesse grupo UNIX.
• Alguns dispositivos com vários processadores (por exemplo, um rádio/modem separado do processador do app) usam soquetes de rede para se comunicar entre processadores. Nesses casos, o socket de rede usado para comunicação entre processadores precisa usar uma interface de rede isolada para impedir o acesso de apps não autorizados no dispositivo. Ou seja, use iptables para impedir o acesso de outros apps no dispositivo.
• Os daemons que processam portas de escuta precisam ser robustos contra dados malformados. O Google pode realizar testes de fuzz na porta usando um cliente não autorizado e, quando possível, um cliente autorizado. Todos os travamentos são registrados como bugs com uma gravidade adequada.

Dados de registro

O registro de dados aumenta o risco de exposição desses dados e reduz o desempenho do sistema. Vários incidentes de segurança públicos ocorreram como resultado do registro de dados sensíveis do usuário por apps instalados por padrão em dispositivos Android. Práticas recomendadas

• Apps ou serviços do sistema não podem registrar dados fornecidos por apps de terceiros que possam incluir informações sensíveis.
• Os apps não podem registrar informações de identificação pessoal (PII) como parte do funcionamento normal.

O CTS inclui testes que verificam a presença de informações potencialmente sensíveis nos registros do sistema.

Limitar o acesso ao diretório

Diretórios graváveis por todos podem apresentar vulnerabilidades de segurança e permitir que um app renomeie arquivos confiáveis, substitua arquivos ou realize ataques baseados em links simbólicos. Os invasores podem usar um link simbólico para um arquivo para enganar um programa confiável e realizar ações que não deveria. Diretórios graváveis também podem impedir que a desinstalação de um app limpe corretamente todos os arquivos associados a ele.

Como prática recomendada, os diretórios criados pelo sistema ou pelos usuários raiz não podem ser graváveis para todos. Os testes do CTS ajudam a aplicar essa prática recomendada testando diretórios conhecidos.

Arquivos de configuração seguros

Muitos drivers e serviços dependem de arquivos de configuração e dados armazenados em diretórios, como /system/etc e /data. Se esses arquivos forem processados por um processo privilegiado e forem graváveis globalmente, será possível que um app explore uma vulnerabilidade no processo criando conteúdos maliciosos no arquivo gravável globalmente. Práticas recomendadas

• Os arquivos de configuração usados por processos privilegiados não podem ser legíveis para todos.
• Os arquivos de configuração usados por processos privilegiados não podem ser graváveis para todos.

Armazenar bibliotecas de código nativo

Qualquer código usado por processos privilegiados do fabricante do dispositivo precisa estar em /vendor ou /system. Esses sistemas de arquivos são montados somente leitura na inicialização. Como prática recomendada, as bibliotecas usadas pelo sistema ou outros apps com privilégios elevados instalados no dispositivo também precisam estar nesses sistemas de arquivos. Isso pode impedir uma vulnerabilidade de segurança que poderia permitir que um atacante controlasse o código executado por um processo privilegiado.

Limitar o acesso ao driver do dispositivo

Somente o código confiável pode ter acesso direto aos drivers. Sempre que possível, a arquitetura preferida é fornecer um daemon de finalidade única que faça proxy de chamadas para o driver e restrinja o acesso do driver a esse daemon. Como prática recomendada, os nós de dispositivos do driver não podem ser lidos ou gravados por todos. Os testes do CTS ajudam a aplicar essa prática recomendada verificando instâncias conhecidas de drivers expostos.

Desativar o ADB

A ponte de depuração do Android (adb) é uma ferramenta valiosa de desenvolvimento e depuração, mas foi projetada para uso em ambientes controlados e seguros e não deve ser ativada para uso geral. Práticas recomendadas

• O ADB precisa estar desativado por padrão.
• O ADB precisa exigir que o usuário o ative antes de aceitar conexões.

Desbloquear carregadores de inicialização

Muitos dispositivos Android oferecem suporte ao desbloqueio, permitindo que o proprietário do dispositivo modifique a partição do sistema e/ou instale um sistema operacional personalizado. Os casos de uso comuns incluem a instalação de uma ROM de terceiros e a realização de desenvolvimento no nível do sistema no dispositivo. Por exemplo, o proprietário de um dispositivo Google Nexus pode executar fastboot oem unlock para iniciar o processo de desbloqueio, que apresenta a seguinte mensagem ao usuário:

Como prática recomendada, os dispositivos Android desbloqueáveis precisam apagar com segurança todos os dados do usuário antes de serem desbloqueados. A falha na exclusão adequada de todos os dados ao desbloquear pode permitir que um invasor fisicamente próximo tenha acesso não autorizado a dados confidenciais do usuário do Android. Para evitar a divulgação de dados do usuário, um dispositivo que ofereça suporte ao desbloqueio precisa implementá-lo corretamente. Já vimos várias instâncias em que os fabricantes de dispositivos implementaram o desbloqueio de forma incorreta. Um processo de desbloqueio implementado corretamente tem as seguintes propriedades:

• Quando o comando de desbloqueio é confirmado pelo usuário, o dispositivo precisa iniciar uma exclusão imediata de dados. A flag unlocked não pode ser definida até que a exclusão segura seja concluída.
• Se não for possível concluir uma exclusão segura, o dispositivo precisa permanecer em um estado bloqueado.
• Se o dispositivo de bloco de dados de destino oferecer suporte, ioctl(BLKSECDISCARD) ou equivalente precisa ser usado. Para dispositivos eMMC, isso significa usar um comando de Limpeza segura ou Trim seguro. Para eMMC 4.5 e versões mais recentes, isso significa usar um Apagar ou Recortar normal seguido por uma operação de Sanitização.
• Se o dispositivo de bloco de dados de BLKSECDISCARD não tiver suporte, ioctl(BLKDISCARD) precisará ser usado. Em dispositivos eMMC, essa é uma operação de corte normal.
• Se não houver suporte para BLKDISCARD, a substituição dos dispositivos de bloco por zeros será aceitável.
• O usuário final precisa ter a opção de exigir que os dados do usuário sejam apagados antes de atualizar uma partição. Por exemplo, em dispositivos Nexus, isso é feito pelo comando fastboot oem lock.
• Um dispositivo pode registrar, por meio de efuses ou mecanismo semelhante, se foi desbloqueado e/ou bloqueado novamente.

Esses requisitos garantem que todos os dados sejam destruídos após a conclusão de uma operação de desbloqueio. A falha na implementação dessas proteções é considerada uma vulnerabilidade de segurança de nível moderado.

Um dispositivo desbloqueado pode ser bloqueado novamente usando o comando fastboot oem lock. O bloqueio do carregador oferece a mesma proteção dos dados do usuário com o novo SO personalizado que estava disponível com o SO original do fabricante do dispositivo. Por exemplo, os dados do usuário serão excluídos se o dispositivo for desbloqueado novamente.