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

Compatibilidade de Política

Este artigo descreve como o Android lida com os problemas de compatibilidade de política com OTAs de plataforma, onde as novas configurações do SELinux da plataforma podem ser diferentes das configurações do SELinux do fornecedor antigo.

Formulação de políticas SELinux baseado em Agudos considera uma distinção binária entre plataforma e política de fornecedor; o esquema torna-se mais complicado se partições fornecedores gerar dependências, como platform < vendor < oem .

No Android 8.0 e superior, a política global SELinux é dividida em componentes privados e públicos. Os componentes públicos consistem na política e na infraestrutura associada, com garantia de disponibilidade para uma versão de plataforma. Esta política será exposta aos redatores da política do fornecedor para permitir que eles criem um arquivo de política do fornecedor, que quando combinado com a política fornecida pela plataforma, resulta em uma política totalmente funcional para um dispositivo.

  • Controle de versão, a política de plataforma pública exportada será escrito como atributos.
  • Para facilitar a escrita política, tipos exportados serão transformados em atributos de versão como parte do processo de construção política. Os tipos públicos também podem ser usados ​​diretamente nas decisões de rotulagem fornecidas pelos arquivos de contexto do fornecedor.

Android mantém um mapeamento entre os tipos de concreto exportados na política de plataforma e os correspondentes atributos de versão para cada versão da plataforma. Isso garante que quando os objetos são rotulados com um tipo, não quebra o comportamento garantido pela política pública da plataforma em uma versão anterior. Este mapeamento é mantido por manter um arquivo de mapeamento de up-to-date para cada versão da plataforma , o que mantém a informação da sociedade atributo para cada tipo de produto exportado em políticas públicas.

Propriedade de objeto e rotulagem

Ao personalizar a política no Android 8.0 e superior, a propriedade deve ser claramente definida para cada objeto para manter a plataforma e a política do fornecedor separadas. Por exemplo, se o fornecedor etiquetas /dev/foo e a plataforma, em seguida, etiquetas /dev/foo em um OTA posterior, haverá um comportamento indefinido. Para o SELinux, isso se manifesta como uma colisão de rotulagem. O nó do dispositivo pode ter apenas um único rótulo que resolve o último rótulo aplicado. Como resultado:

  • Processos que necessitem de acesso a etiqueta sem sucesso aplicado perderá o acesso ao recurso.
  • Processos que ganham acesso ao arquivo pode quebrar porque o nó de dispositivo errado foi criado.

As propriedades do sistema também têm potencial para colisões de nomes que podem resultar em comportamento indefinido no sistema (bem como para rotulagem SELinux). As colisões entre a plataforma e os rótulos do fornecedor podem ocorrer para qualquer objeto que tenha um rótulo SELinux, incluindo propriedades, serviços, processos, arquivos e soquetes. Para evitar esses problemas, defina claramente a propriedade desses objetos.

Além de colisões de rótulos, nomes de tipo / atributo SELinux também podem colidir. Uma colisão de tipo / nome de atributo sempre resultará em um erro do compilador de política.

Espaço de nomes de tipo / atributo

O SELinux não permite várias declarações do mesmo tipo / atributo. A política com declarações duplicadas falhará na compilação. Para evitar tipo e nome do atributo colisões, todas as declarações do fornecedor deve ser namespaced começando com np_ .

type foo, domain; → type np_foo, domain;

Propriedade do sistema e propriedade da rotulagem do processo

Evitar colisões de rótulos é melhor resolvido usando namespaces de propriedade. Para identificar facilmente as propriedades da plataforma e evitar conflitos de nome ao renomear ou adicionar propriedades da plataforma exportada, certifique-se de que todas as propriedades do fornecedor tenham seus próprios prefixos:

Tipo de Propriedade Prefixos aceitáveis
read-write vendor.
somente leitura ro.vendor.
ro.boot.
ro.hardware.
persistente persist.vendor.

Os vendedores podem continuar a usar ro.boot.* (Que vem do cmdline kernel) e ro.hardware.* (Uma propriedade de hardware relacionados com o óbvio).

Todos os serviços do fornecedor em arquivos rc de inicialização deve ter vendor. para serviços em arquivos init rc de partições que não são do sistema. Regras similares são aplicadas aos rótulos SELinux para as propriedades de fornecedores ( vendor_ para as propriedades de fornecedores).

Propriedade do arquivo

Evitar colisões para arquivos é desafiador porque a plataforma e a política do fornecedor geralmente fornecem rótulos para todos os sistemas de arquivos. Ao contrário da nomenclatura de tipo, o namespace de arquivos não é prático, pois muitos deles são criados pelo kernel. Para evitar essas colisões, siga as orientações de nomenclatura para sistemas de arquivos nesta seção. Para o Android 8.0, essas são recomendações sem aplicação técnica. No futuro, essas recomendações serão aplicadas pelo Vendor Test Suite (VTS).

Sistema (/ sistema)

Apenas a imagem do sistema deve fornecer etiquetas para /system componentes através file_contexts , service_contexts , etc. Se as etiquetas de /system componentes são adicionados em /vendor política, um quadro só de atualização OTA pode não ser possível.

Vendedor (/ vendedor)

A política AOSP SELinux já etiquetas partes do vendor de partição as interage plataforma com, que permite escrever regras do SELinux para processos de plataforma a ser capaz de falar e / ou peças de acesso do vendor de partição. Exemplos:

/vendor caminho Etiqueta fornecida pela plataforma Processos de plataforma dependendo da etiqueta
/vendor(/. * )? vendor_file Todos os clientes HAL em quadro, ueventd , etc.
/vendor/framework(/. * )? vendor_framework_file dex2oat , appdomain , etc.
/vendor/app(/. * )? vendor_app_file dex2oat , installd , idmap , etc.
/vendor/overlay(/. * ) vendor_overlay_file system_server , zygote , idmap , etc.

Como resultado, regras específicas devem ser seguidas (aplicada através neverallows ) quando rotular arquivos adicionais em vendor de partição:

  • vendor_file deve ser o rótulo padrão para todos os arquivos em vendor de partição. A política da plataforma exige isso para acessar implementações de HAL de passagem.
  • Todos os novos exec_types adicionados no vendor de partição através fornecedor SEPolicy deve ter vendor_file_type atributo. Isso é aplicado por meio de nunca permite.
  • Para evitar conflitos com futura plataforma / atualizações estruturais, além de arquivos de rotulagem Evitar exec_types em vendor de partição.
  • Todas as dependências da biblioteca para AOSP identificados mesmos HALs processo deve ser rotulado como same_process_hal_file.

Procfs (/ proc)

Os arquivos em /proc podem ser rotulados usando apenas o genfscon rótulo. No Android 7.0, tanto a plataforma e fornecedor política utilizada genfscon para arquivos de etiquetas em procfs .

Recomendação: etiquetas única política plataforma /proc . Se vendor processos precisam de acesso a arquivos em /proc que estão marcados com o rótulo padrão ( proc ), a política fornecedor não deve rotular explicitamente-los e deve usar o genérico proc tipo para adicionar regras para domínios fornecedores. Isso permite que as atualizações de plataforma para acomodar as interfaces do kernel futuras expostas através procfs e rotulá-los explicitamente, conforme necessário.

Debugfs (/ sys / kernel / debug)

Debugfs podem ser rotulados em ambas as file_contexts e genfscon . No Android 7.0 para o Android 10, ambas as plataformas e fornecedores de etiquetas debugfs .

Em Android 11, debugfs não pode ser acessado ou montado em dispositivos de produção. Fabricantes de dispositivos deve remover debugfs .

Tracefs (/ sys / kernel / debug / tracing)

Tracefs podem ser rotulados em ambas as file_contexts e genfscon . No Android 7.0, somente a plataforma etiquetas tracefs .

Recomendação: Apenas plataforma pode rotular tracefs .

Sysfs (/ sys)

Arquivos em /sys podem ser rotulados com as duas file_contexts e genfscon . No Android 7.0, ambas as plataformas e fornecedores de uso file_contexts e genfscon para arquivos de etiquetas em sysfs .

Recomendação: A plataforma pode rotular sysfs nós que não são específicas do dispositivo. Caso contrário, apenas o fornecedor pode rotular os arquivos.

tmpfs (/ dev)

Os arquivos em /dev pode ser etiquetado de file_contexts . No Android 7.0, os arquivos de etiqueta da plataforma e do fornecedor estão aqui.

Recomendação: Vendedor podem rotular arquivos somente em /dev/vendor (por exemplo, /dev/vendor/foo , /dev/vendor/socket/bar ).

Rootfs (/)

Arquivos em / podem ser etiquetadas em file_contexts . No Android 7.0, os arquivos de etiqueta da plataforma e do fornecedor estão aqui.

Recomendação: Apenas sistema pode rotular arquivos em / .

Dados (/ dados)

Os dados são rotulados através de uma combinação de file_contexts e seapp_contexts .

Recomendação: fornecedor rotulagem Disallow fora /data/vendor . Apenas plataforma pode rotular outras partes /data .

Atributos de compatibilidade

A política SELinux é uma interação entre os tipos de origem e destino para classes de objetos e permissões específicas. Cada objeto (processos, arquivos, etc.) afetado pela política SELinux pode ter apenas um tipo, mas esse tipo pode ter vários atributos.

A política é escrita principalmente em termos de tipos existentes:

allow source_type target_type:target_class permission(s);

Isso funciona porque a política foi escrita com conhecimento de todos os tipos. No entanto, se a política do fornecedor e a política da plataforma usam tipos específicos, e o rótulo de um objeto específico muda em apenas uma dessas políticas, a outra pode conter a política que ganhou ou perdeu o acesso anteriormente confiável. Por exemplo:

File_contexts:
/sys/A   u:object_r:sysfs:s0
Platform: allow p_domain sysfs:class perm;
Vendor: allow v_domain sysfs:class perm;

Pode ser alterado para:

File_contexts:
/sys/A   u:object_r:sysfs_A:s0

Embora a política fornecedor permaneceria o mesmo, o v_domain perderia o acesso devido à falta de uma política para o novo sysfs_A tipo.

Ao definir uma política em termos de atributos, podemos dar ao objeto subjacente um tipo que possui um atributo correspondente à política para a plataforma e o código do fornecedor. Isso pode ser feito para todos os tipos para efetivamente criar um-política atributo que tipos de concreto nunca são usadas. Na prática, isso é exigido apenas para as partes da política que se sobrepõem entre a plataforma e fornecedor, que são definidos e fornecidos como política pública plataforma que é construído como parte da política de fornecedor.

Definir a política pública como atributos com versão satisfaz dois objetivos de compatibilidade de política:

  • Certifique-se de código de fornecedor continua a trabalhar após a atualização da plataforma. Obtido adicionando atributos a tipos concretos de objetos correspondentes àqueles nos quais o código do fornecedor se baseava, preservando o acesso.
  • Capacidade de política deprecate. Obtido ao delinear claramente os conjuntos de políticas em atributos que podem ser removidos assim que a versão à qual eles correspondem não for mais compatível. O desenvolvimento pode continuar na plataforma, sabendo que a política antiga ainda está presente na política do fornecedor e será removida automaticamente quando / se houver atualização.

Capacidade de escrita da política

Para atender ao objetivo de não exigir conhecimento de alterações de versão específicas para o desenvolvimento de políticas, o Android 8.0 inclui um mapeamento entre os tipos de políticas públicas de plataforma e seus atributos. Tipo foo é mapeado para atributo foo_v N , onde N é a versão de destino. vN corresponde ao PLATFORM_SEPOLICY_VERSION variável de construção e tem a forma MM.NN , onde MM corresponde ao número de plataforma SDK e NN é uma versão plataforma sepolicy específico.

Os atributos na política pública não têm controle de versão, mas existem como uma API na qual a plataforma e a política do fornecedor podem ser construídas para manter a interface entre as duas partições estável. Os redatores de políticas de plataformas e fornecedores podem continuar a escrever políticas da forma como são escritas hoje.

Política pública Platform exportado como allow source_foo target_bar: class perm ; está incluído como parte da política do fornecedor. Durante a compilação (que inclui a versão correspondente) é transformado em política que vai para a parte fornecedor do dispositivo (mostrado na transformada Common Intermediate Language (CIL)):

 (allow source_foo_vN target_bar_vN (class (perm)))

Como a política do fornecedor nunca está à frente da plataforma, não deve se preocupar com as versões anteriores. No entanto, a política da plataforma precisará saber o quanto é antiga a política do fornecedor, incluir atributos para seus tipos e definir a política correspondente aos atributos com versão.

Política de diffs

Criar automaticamente atributos adicionando _v N para a extremidade de cada tipo não faz nada sem mapeamento de atributos para os tipos em todo Diffs versão. O Android mantém um mapeamento entre as versões de atributos e um mapeamento de tipos para esses atributos. Isso é feito nos arquivos de mapeamento mencionados acima com instruções, como (CIL):

(typeattributeset foo_vN (foo))

Atualizações de plataforma

A seção a seguir detalha cenários para atualizações de plataforma.

Mesmos tipos

Este cenário ocorre quando um objeto não muda os rótulos nas versões da política. Este é o mesmo para os tipos de origem e de destino e pode ser visto com /dev/binder , que é rotulado binder_device em todas as versões. É representado na política transformada como:

binder_device_v1 … binder_device_vN

Ao atualizar do v1v2 , a política de plataforma deve conter:

type binder_device; -> (type binder_device) (in CIL)

No arquivo de mapeamento v1 (CIL):

(typeattributeset binder_device_v1 (binder_device))

No arquivo de mapeamento v2 (CIL):

(typeattributeset binder_device_v2 (binder_device))

Na política do fornecedor v1 (CIL):

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

Na política do fornecedor v2 (CIL):

(typeattribute binder_device_v2)
(allow binder_device_v2 …)
Novos tipos

Este cenário ocorre quando a plataforma adiciona um novo tipo, o que pode acontecer ao adicionar novos recursos ou durante o reforço da política.

  • Novo recurso. Quando o tipo está rotulando um objeto que não existia anteriormente (como um novo processo de serviço), o código do fornecedor não interagiu diretamente com ele, portanto, não existe uma política correspondente. O novo atributo correspondente ao tipo não possui um atributo na versão anterior e, portanto, não precisaria de uma entrada no arquivo de mapeamento destinado a essa versão.
  • Endurecimento da política. Quando o tipo representa endurecimento política, o novo atributo tipo deve ligar de volta para uma cadeia de atributos correspondentes à anterior (semelhante ao exemplo anterior, mudando /sys/A à partir de sysfs para sysfs_A ). Código de fornecedor se baseia em uma regra permitindo o acesso a sysfs , e precisa incluir essa regra como um atributo do novo tipo.

Ao atualizar do v1v2 , a política de plataforma deve conter:

type sysfs_A; -> (type sysfs_A) (in CIL)
type sysfs; (type sysfs) (in CIL)

No arquivo de mapeamento v1 (CIL):

(typeattributeset sysfs_v1 (sysfs sysfs_A))

No arquivo de mapeamento v2 (CIL):

(typeattributeset sysfs_v2 (sysfs))
(typeattributeset sysfs_A_v2 (sysfs_A))

Na política do fornecedor v1 (CIL):

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Na política do fornecedor v2 (CIL):

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)
Tipos removidos

Este cenário (raro) ocorre quando um tipo é removido, o que pode acontecer quando o objeto subjacente:

  • Permanece, mas recebe um rótulo diferente.
  • É removido pela plataforma.

Durante o afrouxamento da política, um tipo é removido e o objeto rotulado com aquele tipo recebe um rótulo diferente já existente. Isso representa uma fusão de mapeamentos de atributos: o código do fornecedor ainda deve ser capaz de acessar o objeto subjacente pelo atributo que ele costumava possuir, mas o resto do sistema agora deve ser capaz de acessá-lo com seu novo atributo.

Se o atributo para o qual foi trocado for novo, então a reclassificação é a mesma que no caso de novo tipo, exceto que quando um rótulo existente é usado, a adição do antigo atributo novo tipo faria com que outros objetos também fossem rotulados com este tipo para ser acessível recentemente. Isso é essencialmente o que é feito pela plataforma e é considerado uma troca aceitável para manter a compatibilidade.

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Versão de exemplo 1: tipos de recolhimento (removendo sysfs_A)

Ao atualizar do v1v2 , a política de plataforma deve conter:

type sysfs; (type sysfs) (in CIL)

No arquivo de mapeamento v1 (CIL):

(typeattributeset sysfs_v1 (sysfs))
(type sysfs_A) # in case vendors used the sysfs_A label on objects
(typeattributeset sysfs_A_v1 (sysfs sysfs_A))

No arquivo de mapeamento v2 (CIL):

(typeattributeset sysfs_v2 (sysfs))

Na política do fornecedor v1 (CIL):

(typeattribute sysfs_A_v1)
(allow … sysfs_A_v1 …)
(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Na política do fornecedor v2 (CIL):

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

Exemplo da versão 2: Removendo completamente (tipo foo)

Ao atualizar do v1v2 , a política de plataforma deve conter:

# nothing - we got rid of the type

No arquivo de mapeamento v1 (CIL):

(type foo) #needed in case vendors used the foo label on objects
(typeattributeset foo_v1 (foo))

No arquivo de mapeamento v2 (CIL):

# nothing - get rid of it

Na política do fornecedor v1 (CIL):

(typeattribute foo_v1)
(allow foo …)
(typeattribute sysfs_v1)
(allow sysfs_v1 …)

Na política do fornecedor v2 (CIL):

(typeattribute sysfs_v2)
(allow sysfs_v2 …)
Nova classe / permissões

Este cenário ocorre quando uma atualização de plataforma introduz novos componentes de política que não existem nas versões anteriores. Por exemplo, quando Android acrescentou o servicemanager gerente de objeto que criou o suplemento, localizar e lista de permissões, daemons de fornecedor que querem registrar com as servicemanager necessárias permissões que não estavam disponíveis. No Android 8.0, apenas a política da plataforma pode adicionar novas classes e permissões.

Para permitir que todos os domínios que poderiam ter sido criados ou estendidos pela política do fornecedor usem a nova classe sem obstrução, a política da plataforma precisa incluir uma regra semelhante a:

allow {domain -coredomain} *:new_class perm;

Isso pode até exigir uma política que permita o acesso a todos os tipos de interface (política pública), para garantir que a imagem do fornecedor obtenha acesso. Se isso resultar em uma política de segurança inaceitável (como pode ter ocorrido com as mudanças do gerenciador de serviços), uma atualização do fornecedor pode ser potencialmente forçada.

Classe / permissões removidas

Este cenário ocorre quando um gerente de objeto é removido (como o ZygoteConnection gerenciador de objetos) e não deve causar problemas. A classe e as permissões do gerenciador de objetos podem permanecer definidas na política até que a versão do fornecedor não as use mais. Isso é feito incluindo as definições no arquivo de mapeamento correspondente.

Personalização do fornecedor para tipos novos / etiquetados novamente

Novos tipos de fornecedores estão no centro do desenvolvimento de políticas de fornecedores, pois são necessários para descrever novos processos, binários, dispositivos, subsistemas e dados armazenados. Como tal, é imperativo permitir a criação de tipos definidos pelo fornecedor.

Como a política do fornecedor é sempre a mais antiga no dispositivo, não há necessidade de converter automaticamente todos os tipos de fornecedor em atributos na política. A plataforma não depende de nada rotulado na política do fornecedor porque a plataforma não tem conhecimento disso; no entanto, a plataforma irá fornecer os atributos e tipos públicos que usa para interagir com os objetos marcados com estes tipos (tais como domain , sysfs_type , etc.). Para a plataforma para continuar para interagir correctamente com estes objectos, os atributos e tipos devem ser adequadamente aplicado e regras específicas podem precisar de ser adicionado aos domínios personalização (tais como init ).

Alterações de atributos para Android 9

Os dispositivos que estão atualizando para o Android 9 podem usar os seguintes atributos, mas os dispositivos que são iniciados com o Android 9 não.

Atributos do violador

O Android 9 inclui estes atributos relacionados ao domínio:

  • data_between_core_and_vendor_violators . Atributo para todos os domínios que violam a exigência de não compartilhar arquivos por caminho entre vendor e coredomains . Os processos da plataforma e do fornecedor não devem usar arquivos em disco para se comunicar (ABI instável). Recomendação:
    • Código de fornecedor deve usar /data/vendor .
    • O sistema não deve usar /data/vendor .
  • system_executes_vendor_violators . Atributo para todos os domínios do sistema (exceto init e shell domains ) que violam a exigência de não executar binários de fornecedores. A execução de binários do fornecedor possui API instável. A plataforma não deve executar binários do fornecedor diretamente. Recomendação:
    • Essas dependências de plataforma nos binários do fornecedor devem estar por trás de HIDL HALs.

      OU

    • coredomains que necessitem de acesso a binários de vendedor deveriam ser movidos para a partição fornecedor e, portanto, deixar de ser coredomain .

Atributos não confiáveis

Aplicativos não confiáveis ​​que hospedam código arbitrário não devem ter acesso aos serviços HwBinder, exceto aqueles considerados suficientemente seguros para acesso a partir de tais aplicativos (consulte serviços seguros abaixo). As duas principais razões para isso são:

  1. Os servidores HwBinder não executam autenticação de cliente porque o HIDL atualmente não expõe informações de UID do chamador. Mesmo se o HIDL expôs esses dados, muitos serviços HwBinder operam em um nível abaixo do dos aplicativos (como HALs) ou não devem depender da identidade do aplicativo para autorização. Assim, para ser seguro, a suposição padrão é que cada serviço HwBinder trata todos os seus clientes como igualmente autorizados a realizar as operações oferecidas pelo serviço.
  2. Servidores HAL (um subconjunto de serviços HwBinder) contêm código com maior taxa de incidência de problemas de segurança do que system/core componentes e ter acesso às camadas inferiores da pilha (todo o caminho para hardware), aumentando assim as oportunidades para contornar o modelo de segurança do Android .

Serviços seguros

Os serviços seguros incluem:

  • same_process_hwservice . Esses serviços (por definição) são executados no processo do cliente e, portanto, têm o mesmo acesso que o domínio do cliente no qual o processo é executado.
  • coredomain_hwservice . Esses serviços não apresentam riscos associados ao motivo nº 2.
  • hal_configstore_ISurfaceFlingerConfigs . Este serviço é projetado especificamente para uso por qualquer domínio.
  • hal_graphics_allocator_hwservice . Essas operações também são oferecidos por surfaceflinger serviço Binder, quais aplicativos têm permissão para acesso.
  • hal_omx_hwservice . Esta é uma versão HwBinder do mediacodec serviço Binder, quais aplicativos têm permissão para acesso.
  • hal_codec2_hwservice . Esta é uma versão mais recente do hal_omx_hwservice .

Atributos utilizáveis

Todos os hwservices não considerados seguros tem o atributo untrusted_app_visible_hwservice . Os servidores HAL correspondentes têm o atributo untrusted_app_visible_halserver . Dispositivos de lançamento com o Android 9 não deve usar qualquer untrusted atributo.

Recomendação:

  • Em vez disso, os aplicativos não confiáveis ​​devem se comunicar com um serviço do sistema que se comunica com o fornecedor HIDL HAL. Por exemplo, os aplicativos podem falar com binderservicedomain , então mediaserver (que é um binderservicedomain ), por sua vez fala ao hal_graphics_allocator .

    OU

  • Aplicativos que precisam de acesso direto ao vendor HAL deve ter seu próprio domínio sepolicy definido pelo fornecedor.

Testes de atributo de arquivo

Android 9 inclui testes de tempo de compilação que garantem todos os arquivos em locais específicos têm os atributos apropriados (tais como, todos os arquivos em sysfs têm o necessário sysfs_type atributo).

Política pública de plataforma

A política pública da plataforma é o núcleo da conformidade com o modelo de arquitetura do Android 8.0 sem simplesmente manter a união das políticas da plataforma v1 e v2. Os fornecedores são expostos a um subconjunto de política plataforma que contém tipos utilizáveis e atributos e regras para estes tipos de atributos e que então se torna parte da política vendedor (isto é, vendor_sepolicy.cil ).

Tipos e regras são automaticamente traduzidos na política do fornecedor gerado em attribute_v N tal que qualquer natureza, desde da plataforma são atributos de versão (no entanto atributos não são versionadas). A plataforma é responsável por mapear os tipos concretos que fornece nos atributos apropriados para garantir que a política do fornecedor continue a funcionar e que as regras fornecidas para uma determinada versão sejam incluídas. A combinação de política pública de plataforma e política de fornecedor satisfaz o objetivo do modelo de arquitetura do Android 8.0 de permitir construções independentes de plataforma e fornecedor.

Mapeamento para cadeias de atributos

Ao usar atributos para mapear para versões de política, um tipo mapeia para um atributo ou vários atributos, garantindo que os objetos rotulados com o tipo sejam acessíveis por meio de atributos correspondentes aos seus tipos anteriores.

Manter o objetivo de ocultar informações de versão do redator da política significa gerar automaticamente os atributos com versão e atribuí-los aos tipos apropriados. No caso comum de tipos estáticos, isso é simples: type_foo mapeia para type_foo_v1 .

Para uma mudança etiqueta objecto tal como sysfssysfs_A ou mediaserveraudioserver , criando este mapeamento não é trivial (e está descrito nos exemplos acima). Os mantenedores da política da plataforma devem determinar como criar o mapeamento em pontos de transição para objetos, o que requer a compreensão do relacionamento entre os objetos e seus rótulos atribuídos e a determinação de quando isso ocorre. Para compatibilidade com versões anteriores, essa complexidade precisa ser gerenciada no lado da plataforma, que é a única partição que pode sofrer uprev.

Versão uprevs

Para simplificar, a plataforma Android lança uma versão sepolicy quando um novo branch de lançamento é cortado. Como descrito acima, o número da versão está contido em PLATFORM_SEPOLICY_VERSION e é da forma MM.nn , onde MM corresponde ao valor SDK e nn é um valor particular mantido em /platform/system/sepolicy. Por exemplo, 19.0 para Kitkat, 21.0 para Pirulito, 22.0 para Lollipop-MR1 23.0 para Guloseima, 24.0 para nougat, 25.0 para nougat-MR1, 26.0 para Oreo, 27.0 para Oreo-MR1, e 28.0 para 9. Android Uprevs não são sempre números inteiros. Por exemplo, se uma colisão MR a um versões necessita de uma mudança incompatível no system/sepolicy/public mas não uma colisão API, então essa versão sepolicy poderia ser: vN.1 . A versão presente em um ramo de desenvolvimento é um não-a-ser-usado-in-transporte marítimo de dispositivos 10000.0 .

O Android pode descontinuar a versão mais antiga ao fazer upgrade. Para saber quando suspender o uso de uma versão, o Android pode coletar o número de dispositivos com políticas do fornecedor que executam essa versão do Android e ainda recebem atualizações importantes da plataforma. Se o número for menor que um certo limite, essa versão está obsoleta.

Impacto de desempenho de vários atributos

Conforme descrito na https://github.com/SELinuxProject/cil/issues/9 , um grande número de atributos atribuído a um resultado tipo de problemas de desempenho em caso de um erro de cache política.

Isto foi confirmado para ser um problema no Android, então as mudanças foram feitas para o Android 8.0 para remover atributos adicionados à política pelo compilador política, bem como para remover atributos não utilizados. Essas mudanças resolveram as regressões de desempenho.

Rotulagem de contextos SELinux

Para oferecer suporte à distinção entre plataforma e sepolicy do fornecedor, o sistema cria arquivos de contexto SELinux de maneira diferente para mantê-los separados.

Contextos de arquivo

Android 8.0 introduziu as seguintes alterações para file_contexts :

  • Para evitar sobrecarga compilação adicional no dispositivo durante a inicialização, file_contexts deixará de existir na forma binária. Em vez disso, eles são legíveis, arquivo regular de texto expressão como {property, service}_contexts (como eles foram pré-7.0).
  • Os file_contexts são divididos entre dois arquivos:
    • plat_file_contexts
      • Plataforma Android file_context que não tem rótulos específicos do dispositivo, com exceção de partes de rotulagem de /vendor de partição que devem ser rotulados com precisão para assegurar o funcionamento adequado dos arquivos sepolicy.
      • Deve residir no system partição no /system/etc/selinux/plat_file_contexts no dispositivo e ser carregado por init no início, juntamente com o fornecedor file_context .
    • vendor_file_contexts
      • Específico do dispositivo file_context construído através da combinação file_contexts encontrados nos diretórios apontado por BOARD_SEPOLICY_DIRS em do dispositivo Boardconfig.mk arquivos.
      • Deve ser instalado no /vendor/etc/selinux/vendor_file_contexts no vendor de partição e ser carregado por init no início, juntamente com a plataforma file_context .

Contextos de propriedade

No Android 8.0, os property_contexts é dividido entre dois arquivos:

  • plat_property_contexts
    • Plataforma Android property_context que não tem rótulos específicos do dispositivo.
    • Deve residir no system partição no /system/etc/selinux/plat_property_contexts e ser carregado por init no início, juntamente com o fornecedor property_contexts .
  • vendor_property_contexts
    • Específico do dispositivo property_context construído através da combinação property_contexts encontrados nos diretórios apontado por BOARD_SEPOLICY_DIRS em do dispositivo Boardconfig.mk arquivos.
    • Deve residir no vendor de partição em /vendor/etc/selinux/vendor_property_contexts e ser carregado por init no início, juntamente com a plataforma property_context

Contextos de serviço

No Android 8.0, os service_contexts é dividida entre os seguintes arquivos:

  • plat_service_contexts
    • Específico da plataforma Android service_context para o servicemanager . O service_context não tem rótulos específicos do dispositivo.
    • Deve residir no system partição no /system/etc/selinux/plat_service_contexts e ser carregado por servicemanager no início, juntamente com o fornecedor service_contexts .
  • vendor_service_contexts
    • Específico do dispositivo service_context construído através da combinação service_contexts encontrados nos diretórios apontado por BOARD_SEPOLICY_DIRS em do dispositivo Boardconfig.mk arquivos.
    • Deve residir no vendor de partição em /vendor/etc/selinux/vendor_service_contexts e ser carregado por servicemanager no início, juntamente com a plataforma service_contexts .
    • Embora servicemanager procura este arquivo em tempo de inicialização, para um totalmente compatível TREBLE dispositivo, os vendor_service_contexts não deve existir. Isto porque toda a interação entre vendor e system processos deve passar por hwservicemanager / hwbinder .
  • plat_hwservice_contexts
    • Plataforma Android hwservice_context para hwservicemanager que não tem rótulos específicos do dispositivo.
    • Deve residir no system partição no /system/etc/selinux/plat_hwservice_contexts e ser carregado por hwservicemanager no início, juntamente com os vendor_hwservice_contexts .
  • vendor_hwservice_contexts
    • Específico do dispositivo hwservice_context construído através da combinação hwservice_contexts encontrados nos diretórios apontado por BOARD_SEPOLICY_DIRS em do dispositivo Boardconfig.mk arquivos.
    • Deve residir no vendor de partição em /vendor/etc/selinux/vendor_hwservice_contexts e ser carregado por hwservicemanager no início, juntamente com os plat_service_contexts .
  • vndservice_contexts
    • Específico do dispositivo service_context para o vndservicemanager construído através da combinação vndservice_contexts encontrados nos diretórios apontado por BOARD_SEPOLICY_DIRS no dispositivo Boardconfig.mk .
    • Este ficheiro tem de residir na vendor partição em /vendor/etc/selinux/vndservice_contexts e ser carregado por vndservicemanager no início.

Contextos Seapp

No Android 8.0, os seapp_contexts é dividido entre dois arquivos:

  • plat_seapp_contexts
    • Plataforma Android seapp_context que não tem mudanças específicas do dispositivo.
    • Deve residir no system partição em /system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • Extensão específica do dispositivo para a plataforma seapp_context construído através da combinação seapp_contexts encontrados nos diretórios apontado por BOARD_SEPOLICY_DIRS no do dispositivo Boardconfig.mk arquivos.
    • Deve residir no vendor de partição em /vendor/etc/selinux/vendor_seapp_contexts .

Permissões MAC

No Android 8.0, o mac_permissions.xml é dividido entre dois arquivos:

  • plataforma mac_permissions.xml
    • Plataforma Android mac_permissions.xml que não tem mudanças específicas do dispositivo.
    • Deve residir no system partição em /system/etc/selinux/.
  • Não Plataforma mac_permissions.xml
    • Extensão específica do dispositivo para a plataforma mac_permissions.xml construído a partir mac_permissions.xml encontrados nos diretórios apontado por BOARD_SEPOLICY_DIRS no do dispositivo Boardconfig.mk arquivos.
    • Deve residir no vendor de partição em /vendor/etc/selinux/.