O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Caixa de areia do aplicativo

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

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 contra aplicativos maliciosos. Para fazer isso, o Android atribui um ID de usuário exclusivo (UID) a cada aplicativo Android e o executa em seu próprio processo.

O Android usa o UID para configurar um Application Sandbox no nível do 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 mal-intencionado, como ler os dados do aplicativo B ou discar para o telefone sem permissão, ele será impedido de fazer isso porque não possui os privilégios de usuário padrão apropriados. O sandbox é simples, auditável e baseado em décadas de separação de processos e permissões de arquivos 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 SO. Todos os softwares acima do kernel, como bibliotecas de SO, estrutura de aplicativos, tempo de execução de aplicativos e todos os aplicativos, são executados no Application Sandbox. Em algumas plataformas, os desenvolvedores sã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 que seja necessário para reforçar a segurança; a esse respeito, o código nativo é tão protegido quanto o código interpretado.

Proteções

Geralmente, para sair do Application Sandbox em um dispositivo configurado corretamente, deve-se comprometer a segurança do kernel Linux. No entanto, semelhante a outros recursos de segurança, as proteções individuais que impõem a sandbox 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 várias proteções para impor a sandbox do aplicativo. Essas imposições foram introduzidas ao longo do tempo e fortaleceram significativamente o sandbox original de controle de acesso discricionário (DAC) baseado em UID. 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 eram executados no mesmo contexto SELinux, de modo que o isolamento entre aplicativos era aplicado principalmente pelo UID DAC.
  • No Android 6.0, o sandbox SELinux foi estendido para isolar aplicativos no limite por usuário físico. Além disso, o Android também define padrões mais seguros para dados de aplicativos: para aplicativos com targetSdkVersion >= 24 , as permissões de DAC padrão no diretório inicial de um aplicativo foram alteradas 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 serem executados com um filtro seccomp-bpf que limitava as syscalls que os aplicativos tinham permissão para usar, fortalecendo assim o limite aplicativo/kernel.
  • No Android 9, todos os aplicativos não privilegiados com targetSdkVersion >= 28 devem ser executados em sandboxes SELinux individuais, fornecendo MAC por aplicativo. Essa proteção melhora a separação de aplicativos, evita 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 mantêm acesso bruto total aos caminhos específicos do pacote, conforme retornado por qualquer método aplicável, como Context.getExternalFilesDir() .

Diretrizes para compartilhar arquivos

Definir os dados do aplicativo como acessíveis ao 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). Essa prática levou a vazamentos de divulgação de informações e vulnerabilidades secundárias confusas, e é um alvo favorito de malware que visa aplicativos com dados confidenciais (como clientes de e-mail). No Android 9 e superior, o compartilhamento de arquivos dessa maneira não é explicitamente permitido para aplicativos com targetSdkVersion>=28 .

Em vez de tornar os dados do aplicativo acessíveis a todos, use as seguintes diretrizes ao compartilhar arquivos:

  • Se seu aplicativo precisar 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 acessíveis do UNIX (para obter detalhes, consulte Princípios básicos do provedor de conteúdo ).
  • Se seu aplicativo tiver arquivos que genuinamente devem ser acessíveis ao mundo (como fotos), eles devem ser específicos de mídia (somente fotos, vídeos e arquivos de áudio) e armazenados usando a classe MediaStore . (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 de tipo fraco, 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 do aplicativo .

  • O valor padrão do sinalizador de manifesto é true para aplicativos direcionados ao Android 9 (e inferior).
  • O valor padrão é false para aplicativos direcionados ao Android 10. Para desativar temporariamente a visualização de armazenamento filtrado em aplicativos direcionados 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 sem área restrita. Os aplicativos que não estão na lista de permissões são colocados em sandbox.