Implementando a segurança

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. Ocasionalmente, também verificamos dispositivos e informamos os fabricantes de dispositivos e parceiros afetados sobre possíveis problemas.

Esta página fornece práticas recomendadas de segurança com base em nossas experiências, ampliando a documentação Projetando para segurança que fornecemos aos desenvolvedores e inclui detalhes exclusivos para criar ou instalar software em nível de 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 no Android Compatibility Test Suite (CTS) e no Android Lint . Incentivamos os implementadores de dispositivos a contribuir com testes que possam ajudar outros usuários do Android (veja 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 em seus processos e ambiente de desenvolvimento.

Revendo o código-fonte

A revisão do código-fonte pode detectar uma ampla gama de problemas de segurança, incluindo aqueles identificados neste documento. O Android incentiva fortemente a revisão manual e automatizada do código-fonte. Melhores Práticas:

• Execute o Android Lint em todos os códigos do aplicativo usando o Android SDK e corrija os problemas identificados.
• O código nativo deve ser analisado usando uma ferramenta automatizada que possa detectar problemas de gerenciamento de memória, como buffer overflows e erros off-by-one.
• O sistema de compilação Android tem suporte para muitos dos sanitizadores LLVM, como AddressSanitizer e UndefinedBehaviorSanitizer, que podem ser usados ​​para essa finalidade.

Usando testes automatizados

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

• 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 todo o processo de desenvolvimento para detectar problemas antecipadamente e reduzir o tempo de correção. O Android usa CTS como parte da integração contínua em nosso processo de compilação automatizado, que é compilado várias vezes por dia.
• Os fabricantes de dispositivos devem automatizar os testes de segurança de interfaces, incluindo testes com entradas malformadas (teste fuzz).

Assinando imagens do sistema

A assinatura da imagem do sistema é crítica para determinar a integridade do dispositivo. Melhores Práticas:

• Os dispositivos não devem ser assinados com uma chave de conhecimento público.
• As chaves usadas para assinar dispositivos devem ser gerenciadas de maneira consistente com as práticas padrão do setor para lidar com chaves confidenciais, incluindo um módulo de segurança de hardware (HSM) que fornece acesso limitado e auditável.

Assinatura de aplicativos (APKs)

As assinaturas de aplicativos desempenham 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 a ser usada para assinar aplicativos, é importante considerar se um aplicativo estará disponível apenas em um único dispositivo ou será comum em vários dispositivos. Melhores Práticas:

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

Publicação de aplicativos

O Google Play oferece aos fabricantes de dispositivos a capacidade de atualizar aplicativos sem realizar uma atualização completa do sistema. Isso pode agilizar a resposta a problemas de segurança e a entrega de novos recursos, além de fornecer uma maneira de garantir que seu aplicativo tenha um nome de pacote exclusivo. Melhores Práticas:

• Faça upload de seus aplicativos para o Google Play para permitir atualizações automatizadas sem exigir uma atualização completa pelo ar (OTA). Os aplicativos carregados, mas não publicados, não podem ser baixados diretamente pelos usuários, mas ainda assim são atualizados. Os usuários que já instalaram o aplicativo podem reinstalá-lo e/ou instalá-lo em outros dispositivos.
• Crie um nome de pacote de aplicativos que esteja claramente associado à sua empresa, como usando a marca registrada da empresa.
• Os aplicativos publicados pelos fabricantes de dispositivos devem ser carregados na Google Play Store para evitar a falsificação de identidade do nome do pacote por usuários terceiros. Se um fabricante de dispositivo instalar um aplicativo em um dispositivo sem publicá-lo na Play Store, outro desenvolvedor poderá fazer upload do mesmo aplicativo, usar o mesmo nome de pacote e alterar os metadados do aplicativo. Quando o aplicativo é apresentado ao usuário, esses metadados não relacionados podem criar confusão.

Respondendo a incidentes

As partes externas devem poder entrar em contato com os fabricantes de dispositivos sobre questões de segurança específicas do dispositivo. Recomendamos a criação de um endereço de e-mail acessível publicamente para gerenciar incidentes de segurança. Melhores Práticas:

• Crie um endereço security@sua-empresa.com ou similar e divulgue-o.
• Se você tomar conhecimento de um problema de segurança que afeta o sistema operacional Android ou dispositivos Android de vários fabricantes de dispositivos, entre em contato com a equipe de segurança do Android preenchendo um relatório de bug de segurança .

Implementação do produto

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

Isolando processos raiz

Os processos raiz são o alvo mais frequente de ataques de escalonamento de privilégios, portanto, a redução do número de processos raiz reduz o risco de escalonamento de privilégios. O CTS inclui um teste informativo que lista os processos raiz. Melhores Práticas:

• Os dispositivos devem executar o código mínimo necessário como root. Sempre que possível, use um processo normal do Android em vez de um processo raiz. O ICS Galaxy Nexus possui apenas seis processos raiz: vold, inetd, zygote, tf_daemon, ueventd e init. Se um processo precisar ser executado como root em um dispositivo, documente o processo em uma solicitação de recurso AOSP para que possa ser revisado publicamente.
• Sempre que possível, o código raiz deve ser isolado de dados não confiáveis ​​e acessado via IPC. Por exemplo, reduza a funcionalidade raiz a um pequeno serviço acessível via Binder e exponha o serviço com permissão de assinatura a um aplicativo com poucos ou nenhum privilégio para lidar com o tráfego de rede.
• Os processos raiz não devem escutar em um soquete de rede.
• Os processos raiz não devem fornecer um tempo de execução de uso geral para aplicativos (por exemplo, um Java VM).

Isolando aplicativos do sistema

Em geral, os aplicativos pré-instalados não devem ser executados com o UID do sistema compartilhado. No entanto, se for necessário que um aplicativo use o UID compartilhado do sistema ou outro serviço privilegiado, o aplicativo não deverá exportar quaisquer serviços, receptores de transmissão ou provedores de conteúdo que possam ser acessados ​​por aplicativos de terceiros instalados pelos usuários. Melhores Práticas:

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

Isolando processos

O Android Application Sandbox fornece aos aplicativos uma expectativa de isolamento de outros processos no sistema, incluindo processos raiz e depuradores. A menos que a depuração seja especificamente habilitada pelo aplicativo e pelo usuário, nenhum aplicativo deverá violar essa expectativa. Melhores Práticas:

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

Protegendo arquivos SUID

Novos programas setuid não devem ser acessíveis por programas não confiáveis. Os programas Setuid têm sido frequentemente locais de vulnerabilidades que podem ser usadas para obter acesso root, portanto, esforce-se para minimizar a disponibilidade do programa Setuid para aplicativos não confiáveis. Melhores Práticas:

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

O verificador CTS inclui um teste informativo listando arquivos SUID; alguns arquivos setuid não são permitidos pelos testes CTS.

Protegendo soquetes de escuta

Os testes CTS falham quando um dispositivo está escutando 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 escuta devem poder ser desativadas sem um OTA. Isso pode ser uma alteração na configuração do servidor ou do dispositivo do usuário.
• Os processos raiz não devem escutar em nenhuma porta.
• Os processos pertencentes ao UID do sistema não devem escutar em nenhuma porta.
• Para IPC local usando soquetes, os aplicativos devem 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. Quaisquer aplicativos cliente devem estar dentro desse grupo UNIX.
• Alguns dispositivos com múltiplos processadores (por exemplo, um rádio/modem separado do processador da aplicação) utilizam soquetes de rede para comunicação entre processadores. Nesses casos, o soquete de rede usado para comunicação entre processadores deve usar uma interface de rede isolada para impedir o acesso de aplicativos não autorizados no dispositivo (ou seja, usar iptables para impedir o acesso de outros aplicativos no dispositivo).
• Os daemons que lidam com portas de escuta devem ser robustos contra dados malformados. O Google pode realizar testes de fuzz na porta usando um cliente não autorizado e, sempre que possível, um cliente autorizado. Quaisquer falhas serão registradas como bugs com gravidade apropriada.

Registrando dados

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ública ocorreram como resultado do registro de dados confidenciais de usuários por aplicativos instalados por padrão em dispositivos Android. Melhores Práticas:

• Os aplicativos ou serviços do sistema não devem registrar dados fornecidos por aplicativos de terceiros que possam incluir informações confidenciais.
• Os aplicativos não devem registrar nenhuma informação de identificação pessoal (PII) como parte da operação normal.

O CTS inclui testes que verificam a presença de informações potencialmente confidenciais nos logs do sistema.

Limitando o acesso ao diretório

Diretórios graváveis ​​mundialmente podem introduzir pontos fracos de segurança e permitir que um aplicativo renomeie arquivos confiáveis, substitua arquivos ou conduza ataques baseados em links simbólicos (os invasores podem usar um link simbólico para um arquivo para enganar um programa confiável para que execute ações que não deveria). Diretórios graváveis ​​também podem impedir que a desinstalação de um aplicativo limpe adequadamente todos os arquivos associados a um aplicativo.

Como prática recomendada, os diretórios criados pelo sistema ou pelos usuários root não devem ser graváveis ​​mundialmente. Os testes CTS ajudam a aplicar essa prática recomendada testando diretórios conhecidos.

Protegendo arquivos de configuração

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 ​​mundialmente, é possível que um aplicativo explore uma vulnerabilidade no processo criando conteúdo malicioso no arquivo gravável mundialmente. Melhores Práticas:

• Os arquivos de configuração usados ​​por processos privilegiados não devem ser legíveis mundialmente.
• Os arquivos de configuração usados ​​por processos privilegiados não devem ser graváveis ​​mundialmente.

Armazenando bibliotecas de código nativo

Qualquer código usado por processos privilegiados de fabricantes de dispositivos deve 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 aplicativos altamente privilegiados instalados no dispositivo também devem estar nesses sistemas de arquivos. Isso pode evitar uma vulnerabilidade de segurança que poderia permitir que um invasor controlasse o código executado por um processo privilegiado.

Limitando o acesso ao driver de dispositivo

Somente código confiável deve ter acesso direto aos drivers. Sempre que possível, a arquitetura preferida é fornecer um daemon de propósito único que faça proxy das chamadas para o driver e restrinja o acesso do driver a esse daemon. Como prática recomendada, os nós de dispositivo de driver não devem ser legíveis ou graváveis ​​mundialmente. Os testes CTS ajudam a aplicar essa prática recomendada, verificando instâncias conhecidas de drivers expostos.

Desativando ADB

O Android debug bridge (adb) é uma ferramenta valiosa de desenvolvimento e depuração, mas foi projetado para uso em ambientes controlados e seguros e não deve ser habilitado para uso geral. Melhores Práticas:

• O ADB deve estar desabilitado por padrão.
• O ADB deve exigir que o usuário o ligue antes de aceitar conexões.

Desbloqueando bootloaders

Muitos dispositivos Android suportam 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 execução de desenvolvimento em nível de 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 ​​devem apagar com segurança todos os dados do usuário antes de serem desbloqueados. A falha em excluir adequadamente todos os dados no desbloqueio pode permitir que um invasor fisicamente próximo obtenha 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 suporte o desbloqueio deve implementá-lo corretamente (vimos vários casos em que os fabricantes de dispositivos implementaram o desbloqueio incorretamente). Um processo de desbloqueio implementado corretamente possui as seguintes propriedades:

• Quando o comando de desbloqueio for confirmado pelo usuário, o dispositivo deverá iniciar uma limpeza imediata de dados. O sinalizador unlocked não deve ser definido até que a exclusão segura seja concluída.
• Se uma exclusão segura não puder ser concluída, o dispositivo deverá permanecer bloqueado.
• Se for suportado pelo dispositivo de bloco subjacente, deve ser usado ioctl(BLKSECDISCARD) ou equivalente. Para dispositivos eMMC, isso significa usar um comando Secure Erase ou Secure Trim. Para o eMMC 4.5 e posterior, isso significa usar um Erase ou Trim normal seguido por uma operação Sanitize.
• Se BLKSECDISCARD não for suportado pelo dispositivo de bloco subjacente, ioctl(BLKDISCARD) deverá ser usado. Em dispositivos eMMC, esta é uma operação normal de Trim.
• Se BLKDISCARD não for suportado, a substituição dos dispositivos de bloco com zeros é aceitável.
• Um usuário final deve 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 por meio do comando fastboot oem lock .
• Um dispositivo pode registrar, por meio de efuses ou mecanismo semelhante, se um dispositivo foi desbloqueado e/ou rebloqueado.

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 posteriormente bloqueado novamente usando o comando fastboot oem lock . Bloquear o bootloader fornece a mesma proteção dos dados do usuário com o novo sistema operacional personalizado que estava disponível com o sistema operacional original do fabricante do dispositivo (por exemplo, os dados do usuário serão apagados se o dispositivo for desbloqueado novamente).