Elementos de apps
O Android oferece uma plataforma de código aberto e um ambiente de app para dispositivos móveis. O sistema operacional principal é baseado no kernel do Linux. Os apps Android são geralmente criados na linguagem de programação Java e executados na máquina virtual do Android Runtime (ART). No entanto, os apps também podem ser escritos em código nativo. Os apps são instalados em um único arquivo com a extensão APK.
Os principais elementos básicos de um app Android são:
-
AndroidManifest.xml: o arquivo AndroidManifest.xml é o arquivo de controle que informa ao sistema o que fazer com todos os componentes de nível superior (especificamente atividades, serviços, broadcast receivers e provedores de conteúdo descritos abaixo) em um app. Ele também especifica quais permissões são necessárias.
-
Atividades: uma atividade é, geralmente, o código de uma única tarefa focada no usuário que usa a classe
Activity. Uma atividade geralmente inclui a exibição de uma interface para o usuário, mas não precisa. Algumas atividades nunca mostram interfaces. Normalmente, uma das atividades do app é o ponto de entrada para um app. -
Serviços: um serviço é um corpo de código executado em segundo plano. Ele pode ser executado no próprio processo ou no contexto do processo de outro app. Outros componentes se "vinculam" a um serviço e invocam métodos nele por chamadas de procedimento remoto. Um exemplo de serviço é um player de mídia: mesmo quando o usuário sai da interface de seleção de mídia, ele provavelmente ainda quer que a música continue tocando. Um serviço mantém a música mesmo quando a interface é concluída.
-
Broadcast receiver: um BroadcastReceiver é um objeto instanciado quando um mecanismo de IPC conhecido como Intent é emitido pelo sistema operacional ou por outro app. Um app pode registrar um receiver para a mensagem de bateria fraca, por exemplo, e mudar o comportamento com base nessas informações.
Modelo de permissão do Android: acesso a APIs protegidas
Todos os apps no Android são executados em um sandbox de aplicativos. Por padrão, um app Android só pode acessar uma variedade limitada de recursos do sistema. O sistema gerencia o acesso de apps Android a recursos que, se usados incorretamente ou maliciosamente, podem afetar negativamente a experiência do usuário, a rede ou os dados no dispositivo.
Essas restrições são implementadas de várias formas. Alguns recursos são restritos por uma falta intencional de APIs para a funcionalidade sensível. Por exemplo, não há uma API do Android para manipular diretamente o cartão SIM. Em alguns casos, a separação de funções oferece uma medida de segurança, como o isolamento de armazenamento por app. Em outros casos, as APIs sensíveis são destinadas ao uso por apps confiáveis e protegidas por um mecanismo de segurança conhecido como permissões.
Essas APIs protegidas incluem:
- Funções da câmera
- Dados de local (GPS)
- Funções do Bluetooth
- Funções de telefonia
- Funções de SMS/MMS
- Conexões de rede/dados
Esses recursos só podem ser acessados pelo sistema operacional. Para usar as APIs protegidas no dispositivo, um app precisa definir os recursos necessários no manifesto. Todas as versões do Android 6.0 e mais recentes usam um modelo de permissões de execução. Se um usuário solicitar um recurso de um app que exige uma API protegida, o sistema vai mostrar uma caixa de diálogo solicitando que o usuário negue ou permita a permissão.
Depois de concedidas, as permissões são aplicadas ao app enquanto ele estiver instalado. Para evitar confusão, o sistema não notifica o usuário novamente sobre as permissões concedidas ao app. Além disso, os apps que são incluídos no sistema operacional principal ou agrupados por um OEM não solicitam permissões ao usuário. As permissões são removidas se um app for desinstalado. Portanto, uma reinstalação subsequente resulta na exibição de permissões.
Nas configurações do dispositivo, os usuários podem conferir as permissões dos apps que já instalaram. Os usuários também podem desativar algumas funcionalidades globalmente quando quiserem, como desativar o GPS, o rádio ou o Wi-Fi.
Caso um app tente usar um recurso protegido que não foi declarado no manifesto, a falha de permissão normalmente resulta em uma exceção de segurança sendo gerada de volta ao app. As verificações de permissão de API protegida são aplicadas no nível mais baixo possível para evitar a evasão. Um exemplo de mensagem do usuário quando um app é instalado enquanto solicita acesso a APIs protegidas é mostrado na Figura 2.
As permissões padrão do sistema estão descritas em https://developer.android.com/reference/android/Manifest.permission.html. Os apps podem declarar as próprias permissões para uso de outros apps. Essas permissões não estão listadas no local acima.
Ao definir uma permissão, um atributo protectionLevel informa ao sistema como o usuário precisa ser informado sobre apps que exigem a permissão ou quem pode manter uma permissão. Detalhes sobre como criar e usar permissões específicas do app são descritos em https://developer.android.com/guide/topics/security/security.html.
Há alguns recursos do dispositivo, como a capacidade de enviar intents de transmissão de SMS, que não estão disponíveis para apps de terceiros, mas que podem ser usados por apps pré-instalados pelo OEM. Essas permissões usam a permissão signatureOrSystem.
Como os usuários entendem os apps de terceiros
O Android se esforça para deixar claro aos usuários quando eles estão interagindo com apps de terceiros e informar os usuários sobre os recursos desses apps. Antes da instalação de qualquer app, o usuário recebe uma mensagem clara sobre as diferentes permissões que o app está solicitando. Após a instalação, o usuário não precisa confirmar as permissões novamente.
Há muitos motivos para mostrar as permissões imediatamente antes da instalação. É quando o usuário está analisando ativamente informações sobre o app, o desenvolvedor e a funcionalidade para determinar se ela corresponde às necessidades e expectativas dele. Também é importante que eles ainda não tenham estabelecido um compromisso mental ou financeiro com o app e que possam comparar o app com outras opções.
Algumas outras plataformas usam uma abordagem diferente para a notificação do usuário, solicitando permissão no início de cada sessão ou enquanto os apps estão em uso. O objetivo do Android é permitir que os usuários alternem entre apps sem problemas. Fornecer confirmações toda vez atrasaria o usuário e impediria que o Android oferecesse uma ótima experiência do usuário. A revisão de permissões no momento da instalação dá ao usuário a opção de não instalar o app se ele se sentir desconfortável.
Além disso, muitos estudos de interface do usuário mostraram que pedir demais ao usuário faz com que ele comece a dizer "OK" para qualquer caixa de diálogo mostrada. Um dos objetivos de segurança do Android é transmitir informações de segurança importantes para o usuário, o que não pode ser feito usando caixas de diálogo que o usuário vai aprender a ignorar. Ao apresentar as informações importantes uma vez e apenas quando for importante, o usuário terá mais chances de pensar sobre o que ele está concordando.
Algumas plataformas optam por não mostrar nenhuma informação sobre a funcionalidade do app. Essa abordagem impede que os usuários entendam e discutam facilmente os recursos do app. Embora não seja possível que todos os usuários sempre tomem decisões totalmente informadas, o modelo de permissões do Android facilita o acesso a informações sobre apps para uma ampla gama de usuários. Por exemplo, solicitações de permissões inesperadas podem fazer com que usuários mais sofisticados façam perguntas importantes sobre a funcionalidade do app e compartilhem as preocupações em lugares como o Google Play, onde ficam visíveis para todos os usuários.
| Permissões na instalação do app: Google Tradutor | Permissões de um app instalado: Gmail |
|---|---|
 |
 |
Figura 1. Exibição de permissões para apps
Comunicação entre processos
Os processos podem se comunicar usando qualquer um dos mecanismos tradicionais do tipo UNIX. Exemplos incluem o sistema de arquivos, soquetes locais ou sinais. No entanto, as permissões do Linux ainda se aplicam.
O Android também oferece novos mecanismos de IPC:
-
Binder: um mecanismo de chamada de procedimento remoto leve baseado em recursos projetado para alto desempenho ao realizar chamadas em processo e entre processos. O Binder é implementado usando um driver Linux personalizado. Consulte https://developer.android.com/reference/android/os/binder.html.
-
Serviços: os serviços (discutidos acima) podem fornecer interfaces diretamente acessíveis usando o binder.
-
Intents: uma intent é um objeto de mensagem simples que representa uma "intenção" de fazer algo. Por exemplo, se o app quiser mostrar uma página da Web, ele vai expressar a "intent" para mostrar o URL criando uma instância de intent e a transmitindo para o sistema. O sistema localiza outra parte do código (neste caso, o navegador) que sabe como processar essa Intent e a executa. As intents também podem ser usadas para transmitir eventos interessantes (como uma notificação) em todo o sistema. Consulte https://developer.android.com/reference/android/content/Intent.html.
-
ContentProviders: um ContentProvider é um repositório de dados que fornece acesso a dados no dispositivo. O exemplo clássico é o ContentProvider que é usado para acessar a lista de contatos do usuário. Um app pode acessar dados que outros apps expuseram por meio de um ContentProvider e também pode definir os próprios ContentProviders para expor dados. Consulte https://developer.android.com/reference/android/content/ContentProvider.html.
Embora seja possível implementar o IPC usando outros mecanismos, como soquetes de rede ou arquivos graváveis globalmente, estes são os frameworks de IPC recomendados para Android. Os desenvolvedores do Android vão ser incentivados a usar as práticas recomendadas para proteger os dados dos usuários e evitar a introdução de vulnerabilidades de segurança.
APIs sensíveis a custos
Uma API sensível a custos é qualquer função que possa gerar um custo para o usuário ou a rede. A plataforma Android colocou APIs sensíveis a custos na lista de APIs protegidas controladas pelo SO. O usuário precisa conceder permissão explícita a apps de terceiros que solicitam o uso de APIs sensíveis a custos. Essas APIs incluem:
- Telefonia
- SMS/MMS
- Rede/dados
- Faturamento no aplicativo
- Acesso por NFC
O Android 4.2 adiciona mais controle sobre o uso de SMS. O Android vai enviar uma notificação se um app tentar enviar um SMS para um código curto que usa serviços premium, o que pode gerar cobranças adicionais. O usuário pode escolher se quer permitir que o app envie a mensagem ou a bloqueie.
Acesso ao chip
O acesso de baixo nível ao chip não está disponível para apps de terceiros. O SO processa todas as comunicações com o chip, incluindo o acesso a informações pessoais (contatos) na memória do chip. Os apps também não podem acessar comandos AT, porque eles são gerenciados exclusivamente pela camada de interface de rádio (RIL). O RIL não oferece APIs de alto nível para esses comandos.
Informações pessoais
O Android colocou APIs que fornecem acesso aos dados do usuário no conjunto de APIs protegidas. Com o uso normal, os dispositivos Android também acumulam dados do usuário em apps de terceiros instalados pelos usuários. Os apps que optam por compartilhar essas informações podem usar verificações de permissão do SO Android para proteger os dados de apps de terceiros.
Figura 2. O acesso a dados sensíveis do usuário só está disponível por APIs protegidas
Os provedores de conteúdo do sistema que provavelmente contêm informações pessoais ou de identificação pessoal, como contatos e agenda, foram criados com permissões claramente identificadas. Essa granularidade fornece ao usuário uma indicação clara dos tipos de informações que podem ser fornecidas ao app. Durante a instalação, um app de terceiros pode solicitar permissão para acessar esses recursos. Se a permissão for concedida, o app poderá ser instalado e terá acesso aos dados solicitados a qualquer momento após a instalação.
Por padrão, os dados coletados por apps que coletam informações pessoais são restritos apenas a esse app. Se um app decidir disponibilizar os dados a outros apps por IPC, o acesso concedido pelo app pode aplicar permissões ao mecanismo de IPC que são aplicadas pelo sistema operacional.
Dispositivos de entrada de dados sensíveis
Os dispositivos Android geralmente oferecem dispositivos de entrada de dados sensíveis que permitem que os apps interajam com o ambiente, como câmera, microfone ou GPS. Para que um app de terceiros acesse esses dispositivos, ele precisa primeiro receber acesso explicitamente do usuário usando as permissões do SO Android. Durante a instalação, o instalador vai solicitar ao usuário a permissão para o sensor por nome.
Se um app quiser saber a localização do usuário, ele vai precisar de uma permissão para acessar o local do usuário. Durante a instalação, o instalador vai pedir ao usuário se o app pode acessar a localização dele. A qualquer momento, se o usuário não quiser que nenhum app acesse a localização dele, ele poderá abrir o app "Configurações", acessar "Localização e segurança" e desmarcar as opções "Usar redes sem fio" e "Ativar satélites GPS". Isso vai desativar os serviços baseados em local para todos os apps no dispositivo do usuário.
Device metadata
O Android também se esforça para restringir o acesso a dados que não são intrinsecamente sensíveis, mas podem revelar indiretamente características sobre o usuário, preferências do usuário e a maneira como ele usa um dispositivo.
Por padrão, os apps não têm acesso a registros do sistema operacional, histórico do navegador, número de telefone ou informações de identificação de hardware / rede. Se um app solicitar acesso a essas informações durante a instalação, o instalador vai perguntar ao usuário se o app pode acessar as informações. Se o usuário não conceder o acesso, o app não será instalado.
Autoridades certificadoras
O Android inclui um conjunto de autoridades certificadoras do sistema instaladas, que são confiáveis em todo o sistema. Antes do Android 7.0, os fabricantes de dispositivos podiam modificar o conjunto de ACs enviados nos dispositivos. No entanto, os dispositivos com a versão 7.0 e mais recentes têm um conjunto uniforme de ACs do sistema, já que a modificação por fabricantes de dispositivos não é mais permitida.
Para ser adicionada como uma nova AC pública ao conjunto padrão do Android, a AC precisa concluir o Processo de inclusão de AC do Mozilla e enviar uma solicitação de recurso para o Android ( https://code.google.com/p/android/issues/entry) para que a AC seja adicionada ao conjunto padrão de ACs do Android no Android Open Source Project (AOSP).
Ainda há ACs específicas do dispositivo que não podem ser incluídas no conjunto principal de ACs do AOSP, como ACs particulares de operadoras que podem ser necessárias para acessar com segurança componentes da infraestrutura da operadora, como gateways de SMS/MMS. Recomendamos que os fabricantes de dispositivos incluam as ACs particulares apenas nos componentes/apps que precisam confiar nelas. Para mais detalhes, consulte Configuração de segurança de rede.
Assinatura de apps
A assinatura de código permite que os desenvolvedores identifiquem o autor do app e façam atualizações sem criar interfaces e permissões complicadas. Todos os apps executados na plataforma Android precisam ser assinados pelo desenvolvedor. Os apps que tentam ser instalados sem serem assinados são rejeitados pelo Google Play ou pelo instalador de pacotes no dispositivo Android.
No Google Play, a assinatura de apps faz a ponte entre a confiança que o Google tem no desenvolvedor e a confiança que o desenvolvedor tem no próprio app. Os desenvolvedores sabem que o app é fornecido sem modificações para o dispositivo Android. Além disso, eles podem ser responsabilizados pelo comportamento do app.
No Android, a assinatura de apps é a primeira etapa para colocar um app no sandbox dele. O certificado do app assinado define qual ID de usuário está associado a qual app. Diferentes apps são executados em diferentes IDs de usuário. A assinatura de apps garante que um app não possa acessar nenhum outro app, exceto por um IPC bem definido.
Quando um app (arquivo APK) é instalado em um dispositivo Android, o Gerenciador de pacotes verifica se o APK foi assinado corretamente com o certificado incluído nesse APK. Se o certificado (ou, mais precisamente, a chave pública no certificado) corresponder à chave usada para assinar qualquer outro APK no dispositivo, o novo APK terá a opção de especificar no manifesto que ele vai compartilhar um UID com os outros APKs assinados da mesma forma.
Os apps podem ser assinados por terceiros (OEM, operador, mercado alternativo) ou autoassinados. O Android oferece assinatura de código usando certificados autoassinados que os desenvolvedores podem gerar sem assistência ou permissão externa. Os apps não precisam ser assinados por uma autoridade central. No momento, o Android não realiza a verificação de AC para certificados de apps.
Os apps também podem declarar permissões de segurança no nível de proteção de assinatura, restringindo o acesso apenas a apps assinados com a mesma chave, mantendo UIDs e sandboxes de aplicativos distintos. Uma relação mais próxima com um Sandbox de aplicativo compartilhado é permitida pelo recurso de UID compartilhado, em que dois ou mais apps assinados com a mesma chave de desenvolvedor podem declarar um UID compartilhado no manifesto.
Verificação de apps
O Android 4.2 e versões mais recentes oferecem suporte à verificação de apps. Os usuários podem ativar a verificação de apps e ter os apps avaliados por um verificador antes da instalação. A verificação de apps pode alertar o usuário se ele tentar instalar um app que possa ser perigoso. Se um app for especialmente nocivo, ele poderá bloquear a instalação.
Gerenciamento de direitos digitais
A plataforma Android oferece um framework extensível de gerenciamento de direitos digitais (DRM) que permite que os apps gerenciem conteúdo protegido por direitos de acordo com as restrições de licença associadas ao conteúdo. O framework de DRM oferece suporte a vários esquemas de DRM. O fabricante do dispositivo decide quais esquemas de DRM ele oferece suporte.
O framework DRM do Android é implementado em duas camadas de arquitetura (consulte a figura abaixo):
-
Uma API de framework DRM, que é exposta aos apps pelo framework do app Android e é executada pela VM do ART para apps padrão.
-
Um gerenciador de DRM de código nativo, que implementa o framework DRM e expõe uma interface para plug-ins de DRM (agentes) para lidar com o gerenciamento de direitos e a descriptografia para vários esquemas de DRM.
Figura 3. Arquitetura de DRM na plataforma Android