O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Sandbox do aplicativo

A plataforma Android aproveita a proteção baseada no usuário do Linux para identificar e isolar recursos de aplicativos. Isso isola os aplicativos uns dos outros e protege os aplicativos e o sistema de aplicativos maliciosos. Para fazer isso, o Android atribui um ID de usuário (UID) exclusivo a cada aplicativo Android e o executa em seu próprio processo.

O Android usa o UID para configurar um Application Sandbox em nível de kernel. O kernel reforça a segurança entre os aplicativos e o sistema no nível do processo por meio de recursos padrão do Linux, como IDs de usuário e grupo atribuídos aos aplicativos. Por padrão, os aplicativos não podem interagir uns com os outros e têm acesso limitado ao sistema operacional. Se o aplicativo A tentar fazer algo malicioso, como ler os dados do aplicativo B ou discar o telefone sem permissão, ele é impedido de fazer isso porque não possui os privilégios de usuário padrão apropriados. A sandbox é simples, auditável e baseada em décadas de separação de processos e permissões de arquivo pelo usuário no estilo UNIX.

Como o Application Sandbox está no kernel, esse modelo de segurança se estende ao código nativo e aos aplicativos do sistema operacional. Todos os softwares acima do kernel, como bibliotecas do sistema operacional, estrutura do aplicativo, tempo de execução do aplicativo e todos os aplicativos, são executados no Application Sandbox. Em algumas plataformas, os desenvolvedores estão restritos a uma estrutura de desenvolvimento específica, conjunto de APIs ou linguagem. No Android, não há restrições sobre como um aplicativo pode ser escrito, o que é necessário para garantir a segurança; a esse respeito, o código nativo é tão seguro quanto o código interpretado.

Proteções

Geralmente, para sair do Application Sandbox em um dispositivo devidamente configurado, é necessário comprometer a segurança do kernel Linux. No entanto, semelhante a outros recursos de segurança, as proteções individuais que aplicam a caixa de proteção do aplicativo não são invulneráveis, portanto, a defesa em profundidade é importante para evitar que vulnerabilidades únicas levem ao comprometimento do sistema operacional ou de outros aplicativos.

O Android conta com uma série de proteções para impor a sandbox do aplicativo. Essas imposições foram introduzidas ao longo do tempo e fortaleceram significativamente a caixa de proteção de controle de acesso discricionário (DAC) baseada em UID original. As versões anteriores do Android incluíam as seguintes proteções:

  • No Android 5.0, o SELinux fornecia separação obrigatória de controle de acesso (MAC) entre o sistema e os aplicativos. No entanto, todos os aplicativos de terceiros foram executados no mesmo contexto SELinux, portanto, o isolamento entre aplicativos foi principalmente aplicado pelo UID DAC.
  • No Android 6.0, o sandbox do SELinux foi estendido para isolar os aplicativos dentro do limite por usuário físico. Além disso, o Android também definiu padrões mais seguros para dados de aplicativos: para aplicativos com targetSdkVersion >= 24 , as permissões DAC padrão no diretório inicial de um aplicativo mudaram de 751 para 700. Isso forneceu um padrão mais seguro para dados de aplicativos privados (embora os aplicativos possam substituir esses padrões) .
  • No Android 8.0, todos os aplicativos foram configurados para rodar com um filtro seccomp-bpf que limitou as syscalls que os aplicativos podiam usar, fortalecendo assim o limite do aplicativo / kernel.
  • No Android 9, todos os aplicativos sem privilégios com targetSdkVersion >= 28 devem ser executados em sandboxes SELinux individuais, fornecendo MAC por aplicativo. Essa proteção melhora a separação de aplicativos, impede a substituição de padrões seguros e (mais significativamente) impede que os aplicativos tornem seus dados acessíveis.
  • No Android 10, os aplicativos têm uma visão bruta limitada do sistema de arquivos, sem acesso direto a caminhos como / sdcard / DCIM. No entanto, os aplicativos retêm acesso bruto total a seus caminhos específicos de pacote, conforme retornado por quaisquer métodos aplicáveis, como Context.getExternalFilesDir () .

Diretrizes para compartilhar arquivos

Definir os dados do aplicativo como acessíveis em todo o mundo é uma prática de segurança ruim. O acesso é concedido a todos e não é possível limitar o acesso apenas ao (s) destinatário (s) pretendido (s). Essa prática levou a vazamentos de divulgação de informações e vulnerabilidades delegadas confusas, e é um alvo favorito para malware que visa aplicativos com dados confidenciais (como clientes de email). No Android 9 e superior, o compartilhamento de arquivos dessa forma é explicitamente proibido para aplicativos com targetSdkVersion>=28 .

Em vez de tornar os dados do aplicativo acessíveis em todo o mundo, use as seguintes diretrizes ao compartilhar arquivos:

  • Se seu aplicativo precisa compartilhar arquivos com outro aplicativo, use um provedor de conteúdo . Os provedores de conteúdo compartilham dados com a granularidade adequada e sem as muitas desvantagens das permissões UNIX acessíveis a todo o mundo (para obter detalhes, consulte Fundamentos do provedor de conteúdo ).
  • Se o seu aplicativo tiver arquivos que deveriam ser genuinamente acessíveis ao mundo (como fotos), eles devem ser específicos para a mídia (fotos, vídeos e arquivos de áudio apenas) e armazenados usando a classeMediaStore . (Para obter mais detalhes sobre como adicionar um item de mídia, consulte Acessar arquivos de mídia do armazenamento compartilhado .)

A permissão de tempo de execução de armazenamento controla o acesso a coleções fortemente tipadas por meio do MediaStore . Para acessar arquivos mal digitados, como PDFs e a classe MediaStore.Downloads , os aplicativos devem usar intents como o intent ACTION_OPEN_DOCUMENT .

Para ativar o comportamento do Android 10, use o atributo de manifesto requestLegacyExternalStorage e siga as práticas recomendadas de permissões de aplicativos .

  • O valor padrão do sinalizador de manifesto é true para aplicativos direcionados ao Android 9 (e inferior).
  • O valor padrão é falso para aplicativos destinados ao Android 10. Para desativar temporariamente a exibição de armazenamento filtrado em aplicativos destinados ao Android 10, defina o valor do sinalizador de manifesto como true .
  • Usando permissões restritas, o instalador coloca na lista de permissões os aplicativos permitidos para armazenamento fora do sandbox. Aplicativos não permitidos são colocados em sandbox.