Como criar políticas do SELinux

O Android Open Source Project (AOSP) oferece uma política de base sólida para o e serviços comuns em todos os dispositivos Android. Os colaboradores do AOSP refinam essa política regularmente. A política principal é esperada representará cerca de 90 a 95% da política final no dispositivo com políticas personalizações formando os 5% a 10% restantes. O foco deste artigo é essas personalizações específicas do dispositivo, como criar uma política específica do dispositivo e algumas armadilhas a serem evitadas.

Exibição do dispositivo

Ao criar uma política específica ao dispositivo, siga estas etapas.

Executar no modo permissivo

Quando um dispositivo estiver modo permissivo, as negações são registradas, mas não aplicadas. O modo permissivo é importante para dois motivos:

  • O modo permissivo garante que a ativação da política não atrase outras para abrir tarefas de inicialização do dispositivo.
  • Uma negação aplicada pode mascarar outras. Por exemplo, o acesso a arquivos normalmente exige uma pesquisa no diretório, a abertura do arquivo e a leitura do arquivo. Em aplicação, apenas a negação de pesquisa de diretório ocorreria. Permissivo garante que todas as negações sejam vistas.

A maneira mais simples de colocar um dispositivo no modo permissivo é usar o Comando kernel linha de comando. Isso pode ser adicionado ao arquivo BoardConfig.mk do dispositivo: platform/device/<vendor>/<target>/BoardConfig.mk. Depois de modificar a linha de comando, execute make clean e make bootimage e atualize a nova imagem de inicialização.

Depois disso, confirme o modo permissivo com:

adb shell getenforce

Duas semanas é um tempo razoável para ficar no modo permissivo global. Depois de lidar com a maioria das negações, volte ao modo de aplicação e resolver bugs conforme eles entram. Os domínios que ainda produzem negações ou serviços em desenvolvimento intenso podem ser colocados temporariamente em modo permissivo, mas de volta ao modo de aplicação assim que possível.

Aplicar com antecedência

No modo de aplicação, as negações são registradas e aplicadas. É um melhor praticar para colocar seu dispositivo em modo de aplicação o mais cedo possível. Aguardando criar e aplicar políticas específicas do dispositivo geralmente resulta em um produto com bugs e uma experiência ruim do usuário. Comece cedo o suficiente para participar dogfood e garantir a cobertura completa de teste da funcionalidade no uso real. Iniciando logo garante que as preocupações com a segurança fundamentem as decisões de design. Por outro lado, conceder permissões baseadas apenas em negações observadas não é uma abordagem segura. Usar hora de realizar uma auditoria de segurança do dispositivo e registrar bugs contra o comportamento isso não deveria ser permitido.

Remover ou excluir política atual

Há vários bons motivos para criar uma política específica do dispositivo a partir de riscar em um novo dispositivo, o que inclui:

Lide com as negações de serviços principais

As recusas geradas pelos serviços principais normalmente são resolvidas pela rotulagem de arquivos. Exemplo:

avc: denied { open } for pid=1003 comm=”mediaserver” path="/dev/kgsl-3d0”
dev="tmpfs" scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0
tclass=chr_file permissive=1
avc: denied { read write } for pid=1003 name="kgsl-3d0" dev="tmpfs"
scontext=u:r:mediaserver:s0
tcontext=u:object_r:device:s0 tclass=chr_file permissive=1

é totalmente resolvido com a identificação adequada de /dev/kgsl-3d0. Em Neste exemplo, tcontext é device. Isso representa contexto padrão, em que tudo em /dev recebe o " device", a menos que um mais específico seja atribuído. Simplesmente aceitar a saída de auditoria2allow aqui resultaria em uma regra incorreta e excessivamente permissiva.

Para resolver esse tipo de problema, dê ao arquivo um rótulo mais específico, que, neste caso é gpu_device. Nenhuma outra permissão é necessária, pois o O mediaserver já tem as permissões necessárias na política principal para acessar o gpu_device.

Outros arquivos específicos do dispositivo que devem ser rotulados com tipos predefinidos em política principal:

Em geral, conceder permissões para rótulos padrão é errado. Muitos desses permissões não permitidas por nuncaallow, mas mesmo quando não for explicitamente proibido, a prática recomendada é fornecer um rótulo.

Rotular novos serviços e endereço negações

Os serviços iniciados pela inicialização precisam ser executados nos próprios domínios SELinux. A exemplo a seguir coloca o serviço “foo” em seu próprio domínio SELinux e concede a ele permissões.

O serviço é iniciado no navegador init.device.rc como:

service foo /system/bin/foo
    class core
  1. Criar um novo domínio "foo"

    Criar o arquivo device/manufacturer/device-name/sepolicy/foo.te com o seguinte conteúdo:

    # foo service
type foo, domain;
type foo_exec, exec_type, file_type;

init_daemon_domain(foo)

    Esse é o modelo inicial para o domínio SELinux foo, ao qual você pode adicionar regras com base nas operações específicas desempenhadas pelo executável.

  2. Marcador /system/bin/foo

    Adicione o seguinte a device/manufacturer/device-name/sepolicy/file_contexts:

    /system/bin/foo   u:object_r:foo_exec:s0

    Isso garante que o executável seja devidamente rotulado, para que o SELinux execute a no domínio correto.

  3. Crie e atualize as imagens de inicialização e do sistema.
  4. Refinar as regras do SELinux para o domínio.

    Use as recusas para determinar as permissões necessárias. A auditoria2allow fornece boas diretrizes, mas só o utiliza para embasar a escrever. Não basta copiar a saída.

Voltar para o modo aplicado

Não há problema em resolver problemas no modo permissivo, mas volte a aplicar o mais cedo possível e tente permanecer nele.

Erros comuns

Aqui estão algumas soluções para erros comuns que ocorrem ao escrever e políticas específicas do dispositivo.

Uso excessivo de negação

O exemplo de regra a seguir é como trancar a porta da frente, mas deixar janelas abertas:

allow { domain -untrusted_app } scary_debug_device:chr_file rw_file_perms

A intenção é clara: todos, exceto aplicativos de terceiros, podem ter acesso ao arquivo de depuração dispositivo.

A regra tem alguns erros. A exclusão de untrusted_app é simples de se contorná-lo, pois todos os aplicativos podem, opcionalmente, executar serviços na isolated_app. Da mesma forma, se novos domínios para apps de terceiros forem adicionados ao AOSP, eles também terão acesso a scary_debug_device. A regra é excessivamente permissiva. A maioria dos domínios não vai se beneficiar de ter acesso a essa ferramenta de depuração. A regra deveria ter sido criada para permitir os domínios que exigem acesso.

Como depurar recursos em produção

Os recursos de depuração não devem estar presentes em builds de produção, política.

A alternativa mais simples é permitir o recurso de depuração somente quando o SELinux estiver desativada em builds eng/userdebug, como adb root e adb shell setenforce 0.

Outra alternativa segura é incluir as permissões de depuração em um userdebug_or_eng.

Explosão do tamanho da política

Caracterização das políticas do SEAndroid na natureza descreve uma tendência preocupante no crescimento das personalizações de políticas dos dispositivos. A política específica ao dispositivo deve representar de 5 a 10% da política geral em execução no um dispositivo. As personalizações acima de 20%certamente contêm mais de domínios privilegiados e políticas inativas.

Política desnecessariamente grande:

  • Tem uma falha dupla na memória enquanto a política fica no ramdisk e é também são carregados na memória do kernel.
  • Desperdiça espaço em disco ao exigir uma imagem de inicialização maior.
  • Afeta os tempos de pesquisa da política de ambiente de execução.

O exemplo a seguir mostra dois dispositivos em que as especificações do fabricante por 50% e 40% da política no dispositivo. Uma reescrita da política rendeu melhorias de segurança substanciais sem perda de funcionalidade, já que mostradas abaixo. Os dispositivos AOSP Shamu e Flounder estão incluídos para comparação.

Figura 1: comparação do tamanho da política específica do dispositivo após a auditoria de segurança.

Figura 1. Comparação de dispositivos específicos tamanho da política após a auditoria de segurança.

Em ambos os casos, a política foi drasticamente reduzida em tamanho e número de permissões. A redução do tamanho da política se deve quase que inteiramente devido à remoção permissões desnecessárias, muitas das quais eram prováveis regras geradas audit2allow que foram adicionados indiscriminadamente à política. -morta domínios.

Como conceder o recurso dac_override

Uma negação dac_override significa que o processo ofensivo está Tentativa de acessar um arquivo com as permissões de usuário/grupo/mundo Unix incorretas. A solução correta é quase nunca conceder a permissão dac_override. Em vez disso, mudar as permissões do Unix no arquivo ou processo Alguns domínios, como init, vold e installd precisam de verdade a capacidade de substituir as permissões de arquivos Unix para acessar arquivos de outros processos. Consulte o blog de Dan Walsh (em inglês) para uma explicação mais detalhada.