Sandbox de aplicativos

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

O Android usa o UID para configurar um sandbox de aplicativos no nível do kernel. O kernel reforça a segurança entre os apps e o sistema no nível do processo por meio de recursos padrão do Linux, como IDs de usuário e de grupo atribuídos a apps. Por padrão, os apps não podem interagir entre si e têm acesso limitado ao SO. Se o app A tentar fazer algo malicioso, como ler os dados do app B ou discar o telefone sem permissão, ele não poderá fazer isso porque não tem os privilégios de usuário padrão adequados. O sandbox é simples, auditável e baseado em um sistema de usuário antigo separação de processos e permissões de arquivo.

Como o sandbox do aplicativo está no kernel, esse modelo de segurança se estende ao código nativo e aos apps do SO. Todo o software acima do como bibliotecas do SO, framework e ambiente de execução do app, todos os aplicativos, executados no sandbox do aplicativo. Em algumas plataformas, desenvolvedores estão restritos a uma estrutura de desenvolvimento específica, um conjunto de APIs ou idioma de destino. No Android, não há restrições sobre como um app pode ser escrito que sejam necessárias para aplicar a segurança. Nesse sentido, o código nativo é colocado em sandbox como código interpretado.

Proteções

Em geral, para sair do sandbox de aplicativos em um ambiente dispositivo, é preciso comprometer a segurança do kernel do Linux. No entanto, semelhantes a outros recursos de segurança, as proteções individuais sandbox não são invulneráveis, logo, defesa em profundidade é importante para evitar que vulnerabilidades únicas levem ao comprometimento do SO ou de outros apps.

O Android depende de várias proteções para aplicar o sandbox do app. Essas restrições foram introduzidas ao longo do tempo e fortaleceu significativamente o controle de acesso discricionário baseado em UID original (DAC). As versões anteriores do Android incluíam as seguintes proteções:

• No Android 5.0, o SELinux oferecia separação obrigatória de controle de acesso (MAC) entre o sistema e os aplicativos. No entanto, todos os apps de terceiros eram executados no mesmo contexto do SELinux, então o isolamento entre apps era aplicado principalmente pelo UID DAC.
• No Android 6.0, o sandbox do SELinux foi estendido para isolar aplicativos na limite por usuário físico. Além disso, o Android também definiu padrões mais seguros para dados de apps: para apps com targetSdkVersion >= 24, padrão As permissões do DAC no diretório inicial de um app foram alteradas de 751 para 700. Isso forneceu um padrão mais seguro para dados de apps particulares, embora os apps possam substituir esses padrões.
• No Android 8.0, todos os apps foram configurados para serem executados com um seccomp-bpf. que limitava as chamadas do sistema que os aplicativos podiam usar, o que Fortalecimento do limite app/kernel.
• No Android 9, todos os apps não privilegiados com targetSdkVersion >= 28 precisam ser executados em sandboxes SELinux individuais, fornecendo o MAC em um por app base. Essa proteção melhora a separação de apps e impede a substituição de apps seguros e, mais significativamente, impede que os apps transformem dados acessíveis.
• No Android 10, os apps têm uma visualização bruta limitada do sistema de arquivos, sem acesso direto a caminhos como /sdcard/DCIM. No entanto, os apps mantêm acesso bruto completo aos caminhos específicos do pacote, quando retornados por métodos aplicáveis, como Context.getExternalFilesDir().

Diretrizes para o compartilhamento de arquivos

Definir os dados do app como acessíveis no mundo todo é uma prática de segurança ruim. Acesso é concedido a todos, e não é possível limitar o acesso apenas destinatário(s). Essa prática levou a vazamentos de informações e vulnerabilidades de subdelegação, e é o alvo favorito de malwares que visam apps com dados sensíveis (como clientes de e-mail). No Android 9 e versões mais recentes, dessa forma é expressamente proibida para aplicativos com targetSdkVersion>=28:

Em vez de tornar os dados do app acessíveis mundialmente, use as seguintes diretrizes ao compartilhar arquivos:

• Caso seu app precise compartilhar arquivos com outro, 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 de acesso universal do UNIX. Para saber mais, consulte Fundamentos do provedor de conteúdo.
• Caso seu app tenha arquivos que realmente deveriam estar acessíveis ao mundo todo (como fotos), eles precisam ser específicos da mídia (fotos, vídeos e arquivos de áudio). ) e armazenados usando o MediaStore. Para mais detalhes sobre como adicionar uma mídia item, consulte Acessar arquivos de mídia do armazenamento compartilhado.

A permissão de tempo de execução Armazenamento controla o acesso a coleções com tipo forte pela MediaStore. Para acessar arquivos com tipificação fraca, como PDFs e a classe MediaStore.Downloads, os apps precisam usar intents como a ACTION_OPEN_DOCUMENT.

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

• O valor padrão da flag do manifesto é true para apps destinados ao Android 9 (e versões anteriores).
• O valor padrão é falso para apps destinados ao Android 10. Para desativar temporariamente as armazenamento em apps destinados ao Android 10, Defina o valor da flag do manifesto como true.
• Usando permissões restritas, o instalador autoriza apps com permissão para armazenamento sem sandbox. Apps que não estão na lista de permissões são no sandbox.