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 os dispositivos e informamos os fabricantes de dispositivos e os parceiros afetados sobre possíveis problemas.

Esta página fornece as práticas recomendadas de segurança com base em nossas experiências, estendendo a documentação do Designing for Security que fornecemos para desenvolvedores e inclui detalhes exclusivos para criar ou instalar software de 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 seguintes práticas recomendadas em seus processos e ambiente de desenvolvimento.

Revisando o código-fonte

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

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

Usando testes automatizados

Os testes automatizados podem detectar uma ampla variedade 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 o 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 das interfaces, incluindo testes com entradas malformadas (teste fuzz).

Imagens do sistema de assinatura

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 conhecida publicamente.
• 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.

Aplicativos de assinatura (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 para usar para assinar aplicativos, é importante considerar se um aplicativo estará disponível apenas em um único dispositivo ou comum em vários dispositivos. Melhores Práticas:

• Os aplicativos não devem ser assinados com uma chave conhecida publicamente.
• 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 fornece 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 de 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 pacote exclusivos por dispositivo e chave.

Aplicativos de publicação

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:

• Carregue seus aplicativos no Google Play para permitir atualizações automatizadas sem exigir uma atualização completa por via aérea (OTA). Os aplicativos carregados, mas não publicados, não podem ser baixados diretamente pelos usuários, mas os aplicativos ainda são atualizados. Os usuários que instalaram o aplicativo anteriormente podem reinstalá-lo e/ou instalá-lo em outros dispositivos.
• Crie um nome de pacote de aplicativos que esteja claramente associado à sua empresa, por exemplo, usando uma marca registrada da empresa.
• Os aplicativos publicados por fabricantes de dispositivos devem ser carregados na Google Play Store para evitar a falsificação de identidade do nome do pacote por usuários de 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 ter a capacidade de entrar em contato com os fabricantes de dispositivos sobre problemas de segurança específicos 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@your-company.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 seguintes práticas recomendadas ao implementar um produto.

Isolando processos raiz

Os processos raiz são o alvo mais frequente de ataques de escalonamento de privilégios, portanto, reduzir o 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 Android normal em vez de um processo raiz. O ICS Galaxy Nexus tem apenas seis processos raiz: vold, inetd, zygote, tf_daemon, ueventd e init. Se um processo deve 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 para 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, uma 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 deve exportar nenhum serviço, broadcast receiver ou provedor de conteúdo que possa ser acessado 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 habilitada especificamente pelo aplicativo e pelo usuário, nenhum aplicativo deve 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 Android documentado.
• Os processos raiz não devem acessar a memória dos aplicativos, a menos que usem um método de depuração Android documentado.
• 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 o local 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 burlar 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 ​​em todo o mundo. Crie um grupo, limite o acesso ao binário SUID aos membros desse grupo e coloque quaisquer aplicativos que possam executar o programa SUID nesse grupo.
• Os programas SUID são uma fonte comum de enraizamento de dispositivos pelo usuário. Para reduzir esse risco, os programas SUID não devem ser executáveis ​​pelo usuário do shell.

O verificador CTS inclui um teste informativo listando arquivos SUID; alguns arquivos setuid não são permitidos por 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 desabilitadas 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. Qualquer aplicativo cliente deve estar dentro desse grupo UNIX.
• Alguns dispositivos com vários processadores (por exemplo, um rádio/modem separado do processador do aplicativo) usam soquetes de rede para comunicação entre os 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, use iptables para impedir o acesso de outros aplicativos no dispositivo).
• Daemons que lidam com portas de escuta devem ser robustos contra dados malformados. O Google pode realizar testes fuzz na porta usando um cliente não autorizado e, sempre que possível, um cliente autorizado. Quaisquer falhas serão arquivadas como bugs com uma gravidade apropriada.

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ública ocorreram como resultado do registro de dados confidenciais do usuário 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 ​​em todo o mundo podem apresentar falhas 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 a realizar ações que não deveriam). Os 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 usuários root não devem ser graváveis ​​em todo o mundo. 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 universal. Melhores Práticas:

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

Armazenando bibliotecas de código nativo

Qualquer código usado por processos de fabricantes de dispositivos privilegiados 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 pode permitir que um invasor controle o código executado por um processo privilegiado.

Limitando o acesso ao driver do dispositivo

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

Desativando 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 habilitada para uso geral. Melhores Práticas:

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

Desbloqueando carregadores de inicialização

Muitos dispositivos Android suportam o 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 corretamente todos os dados no desbloqueio pode permitir que um invasor fisicamente próximo obtenha acesso não autorizado a dados confidenciais de usuários do Android. Para evitar a divulgação de dados do usuário, um dispositivo que oferece suporte ao desbloqueio deve implementá-lo corretamente (já vimos vários casos em que os fabricantes de dispositivos implementaram o desbloqueio incorretamente). Um processo de desbloqueio implementado corretamente tem as seguintes propriedades:

• Quando o comando de desbloqueio é confirmado pelo usuário, o dispositivo deve iniciar uma limpeza de dados imediata. 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 em um estado bloqueado.
• Se suportado pelo dispositivo de bloco subjacente, ioctl(BLKSECDISCARD) ou equivalente deve ser usado. Para dispositivos eMMC, isso significa usar um comando Secure Erase ou Secure Trim. Para eMMC 4.5 e posterior, isso significa usar uma operação normal de Erase ou Trim seguido por uma operação de 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 todos os 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 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).