Para melhorar a segurança do dispositivo, o Android 7.0 divide o processo monolítico do servidor de mediaserver em vários processos com permissões e recursos restritos apenas aos exigidos por cada processo. Essas alterações mitigam as vulnerabilidades de segurança da estrutura de mídia:
- Divisão de componentes de pipeline AV em processos de área restrita específicos do aplicativo.
- Habilitando componentes de mídia atualizáveis (extratores, codecs, etc.).
Essas mudanças também melhoram a segurança dos usuários finais, reduzindo significativamente a gravidade da maioria das vulnerabilidades de segurança relacionadas à mídia, mantendo os dispositivos e os dados do usuário final seguros.
OEMs e fornecedores de SoC precisam atualizar suas alterações de HAL e estrutura para torná-los compatíveis com a nova arquitetura. Especificamente, como o código Android fornecido pelo fornecedor geralmente assume que tudo é executado no mesmo processo, os fornecedores devem atualizar seu código para transmitir identificadores nativos ( native_handle ) que tenham significado entre os processos. Para uma implementação de referência de mudanças relacionadas ao fortalecimento de mídia, consulte frameworks/av e frameworks/native .
Mudanças arquitetônicas
As versões anteriores do Android usavam um único processo de servidor de mediaserver monolítico com muitas permissões (acesso à câmera, acesso ao áudio, acesso ao driver de vídeo, acesso a arquivos, acesso à rede, etc.). O Android 7.0 divide o processo mediaserver em vários novos processos, cada um exigindo um conjunto muito menor de permissões:
Figura 1. Mudanças de arquitetura para proteção do mediaserver
Essa nova arquitetura garante que, mesmo que um processo seja comprometido, o código malicioso não tenha acesso ao conjunto completo de permissões anteriormente mantidas pelo mediaserver. Os processos são restritos pelas políticas SElinux e secomp.
Observação: devido às dependências do fornecedor, alguns codecs ainda são executados no mediaserver e, consequentemente, concedem mediaserver mais permissões do que o necessário. Especificamente, Widevine Classic continua a ser executado no mediaserver para Android 7.0.
Alterações do MediaServer
No Android 7.0, o processo mediaserver existe para conduzir a reprodução e gravação, por exemplo, passando e sincronizando buffers entre componentes e processos. Os processos se comunicam por meio do mecanismo padrão do Binder.
Em uma sessão de reprodução de arquivo local padrão, o aplicativo passa um descritor de arquivo (FD) para o mediaserver (geralmente por meio da API Java do MediaPlayer) e o mediaserver :
- Agrupa o FD em um objeto Binder DataSource que é passado para o processo extrator, que o usa para ler o arquivo usando o Binder IPC. (O mediaextractor não obtém o FD, mas faz o Binder chamar de volta ao
mediaserverpara obter os dados.) - Examina o arquivo, cria o extrator apropriado para o tipo de arquivo (por exemplo, MP3Extractor ou MPEG4Extractor) e retorna uma interface Binder do extrator para o processo
mediaserver. - Faz chamadas IPC do Binder para o extrator para determinar o tipo de dados no arquivo (por exemplo, dados MP3 ou H.264).
- Chama o processo
mediacodecpara criar codecs do tipo necessário; recebe interfaces do Binder para esses codecs. - Faz chamadas repetidas do Binder IPC para o extrator para ler amostras codificadas, usa o Binder IPC para enviar dados codificados ao processo
mediacodecpara decodificação e recebe dados decodificados.
Em alguns casos de uso, nenhum codec está envolvido (como uma reprodução descarregada onde os dados codificados são enviados diretamente para o dispositivo de saída), ou o codec pode renderizar os dados decodificados diretamente em vez de retornar um buffer de dados decodificados (reprodução de vídeo).
Alterações no MediaCodecService
O serviço de codec é onde os codificadores e decodificadores vivem. Devido às dependências do fornecedor, nem todos os codecs ainda estão no processo de codecs. No Android 7.0:
- Decodificadores e codificadores de software não seguros vivem no processo de codec.
- Decodificadores seguros e codificadores de hardware vivem no servidor de
mediaserver(inalterado).
Um aplicativo (ou servidor de mídia) chama o processo de codec para criar um codec do tipo necessário e, em seguida, chama esse codec para transmitir dados codificados e recuperar dados decodificados (para decodificação) ou para transmitir dados decodificados e recuperar dados codificados (para codificação) . A transferência de dados de e para codecs já usa memória compartilhada, de modo que o processo permanece inalterado.
Alterações do MediaDrmServer
O servidor DRM é usado ao reproduzir conteúdo protegido por DRM, como filmes no Google Play Filmes. Ele lida com a descriptografia dos dados criptografados de maneira segura e, como tal, tem acesso ao armazenamento de certificados e chaves e outros componentes confidenciais. Devido às dependências do fornecedor, o processo DRM ainda não é usado em todos os casos.
Alterações do servidor de áudio
O processo AudioServer hospeda componentes relacionados ao áudio, como entrada e saída de áudio, o serviço policymanager que determina o roteamento de áudio e o serviço de rádio FM. Para obter detalhes sobre alterações de áudio e orientações de implementação, consulte Implementando áudio .
Alterações do CameraServer
O CameraServer controla a câmera e é usado na gravação de vídeo para obter quadros de vídeo da câmera e depois passá-los para o mediaserver para manuseio posterior. Para obter detalhes sobre alterações e orientações de implementação para alterações do CameraServer, consulte Camera Framework Hardening .
Alterações no ExtractorService
O serviço extrator hospeda os extratores , componentes que analisam os vários formatos de arquivo suportados pela estrutura de mídia. O serviço extrator é o menos privilegiado de todos os serviços - ele não pode ler FDs, então faz chamadas para uma interface Binder (fornecida a ele pelo mediaserver for cada sessão de reprodução) para acessar arquivos.
Um aplicativo (ou mediaserver ) faz uma chamada para o processo extrator para obter um IMediaExtractor , chama esse IMediaExtractor para obter IMediaSources para a faixa contida no arquivo e, em seguida, chama IMediaSources para ler os dados deles.
Para transferir os dados entre processos, o aplicativo (ou mediaserver ) inclui os dados no pacote de resposta como parte da transação Binder ou usa memória compartilhada:
- O uso de memória compartilhada requer uma chamada extra do Binder para liberar a memória compartilhada, mas é mais rápido e usa menos energia para buffers grandes.
- Usar in-Parcel requer cópia extra, mas é mais rápido e usa menos energia para buffers menores que 64 KB.
Implementação
Para oferecer suporte à movimentação dos componentes MediaDrm e MediaCrypto para o novo processo mediadrmserver , os fornecedores devem alterar o método de alocação de buffers seguros para permitir que os buffers sejam compartilhados entre os processos.
Nas versões anteriores do Android, os buffers seguros são alocados no mediaserver pelo OMX::allocateBuffer e usados durante a descriptografia no mesmo processo, conforme mostrado abaixo:
Figura 2. Android 6.0 e alocação de buffer inferior no mediaserver.
No Android 7.0, o processo de alocação de buffer mudou para um novo mecanismo que oferece flexibilidade e minimiza o impacto nas implementações existentes. Com as pilhas MediaDrm e MediaCrypto no novo processo mediadrmserver , os buffers são alocados de maneira diferente e os fornecedores devem atualizar os identificadores de buffer seguros para que possam ser transportados pelo fichário quando o MediaCodec invocar uma operação de descriptografia no MediaCrypto .
Figura 3. Alocação de buffer do Android 7.0 e superior no mediaserver.
Usando identificadores nativos
O OMX::allocateBuffer deve retornar um ponteiro para uma estrutura native_handle , que contém descritores de arquivo (FDs) e dados inteiros adicionais. Um native_handle tem todas as vantagens de usar FDs, incluindo suporte de binder existente para serialização/desserialização, enquanto permite mais flexibilidade para fornecedores que não usam FDs atualmente.
Use native_handle_create() para alocar o identificador nativo. O código do framework se apropria da estrutura native_handle alocada e é responsável por liberar recursos no processo em que o native_handle é originalmente alocado e no processo em que é desserializado. A estrutura libera identificadores nativos com native_handle_close() seguido por native_handle_delete() e serializa/desserializa o native_handle usando Parcel::writeNativeHandle()/readNativeHandle() .
Os fornecedores de SoC que usam FDs para representar buffers seguros podem preencher o FD no native_handle com seu FD. Os fornecedores que não usam FDs podem representar buffers seguros usando campos adicionais no native_buffer .
Configurando o local de descriptografia
Os fornecedores devem atualizar o método de descriptografia OEMCrypto que opera no native_handle para executar quaisquer operações específicas do fornecedor necessárias para tornar o native_handle utilizável no novo espaço de processo (as alterações geralmente incluem atualizações nas bibliotecas OEMCrypto).
Como allocateBuffer é uma operação OMX padrão, o Android 7.0 inclui uma nova extensão OMX ( OMX.google.android.index.allocateNativeHandle ) para consultar esse suporte e uma chamada OMX_SetParameter que notifica a implementação OMX de que deve usar identificadores nativos.