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

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 Linux padrão, como IDs de usuário e grupo que são 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 será 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. Todo o software 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 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 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 SELinux foi estendido para isolar os aplicativos dentro do limite por usuário físico. Além disso, o Android também definir padrões mais seguras para dados de aplicativo: Para aplicações com targetSdkVersion >= 24 , permissões CAD padrão no diretório home de um aplicativo passou de 751 para 700. Isso proporcionou padrão mais seguro para dados de aplicativos privados (embora aplicativos podem substituir esses padrões) .
  • No Android 8.0, todos os aplicativos foram criados para funcionar com um seccomp-bpf filtro que limita os syscalls que os aplicativos foram autorizados a usar, reforçando, assim, o aplicativo / kernel limite.
  • Em Android 9 todos os aplicativos não-privilegiados com targetSdkVersion >= 28 deve ser executado em caixas de areia SELinux individuais, proporcionando MAC em uma base 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, as aplicações reter acesso em bruto integral para os seus caminhos específicos do pacote, como retornado por quaisquer métodos aplicáveis, tais 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 insatisfatória. 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 e-mail). Em Android 9 e superior, o compartilhamento de arquivos desta forma é explicitamente anulado por 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 as suas necessidades de aplicativos para compartilhar arquivos com outro aplicativo, usar um provedor de conteúdo . Os provedores de conteúdo compartilhar os dados com a granularidade adequada e sem as muitas desvantagens do mundo acessível permissões UNIX (para detalhes, consulte básico provedor de conteúdo ).
  • Se seu aplicativo tem arquivos que realmente deveriam estar acessíveis para o mundo (como fotos), eles devem ser (fotos, vídeos e arquivos de áudio apenas) específicos de mídia e armazenados usando o MediaStore classe. (Para mais detalhes sobre como adicionar um item de mídia, ver arquivos de mídia de acesso de armazenamento compartilhado .)

Os controles de permissão de execução de armazenamento de acesso à rigidez de tipos coleções através MediaStore. Para acessar arquivos fracamente digitadas, como PDFs e do MediaStore.Downloads classe, os aplicativos devem usar os intentos como o ACTION_OPEN_DOCUMENT intenção.

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

  • O valor padrão da bandeira manifesto é true para aplicações dirigidas Android 9 (e inferior).
  • O valor padrão é falso para aplicativos visando Android 10. Para optar temporariamente fora da exibição de armazenamento filtrada em aplicativos visando Android 10, definir o valor da bandeira manifesto para true .
  • Usando permissões restritas, o instalador coloca na lista de permissões os aplicativos permitidos para armazenamento fora da área restrita. Os aplicativos não permitidos são colocados em sandbox.