Conceitos do SELinux

Consulte esta página para se familiarizar com os conceitos do SELinux.

Controle de acesso obrigatório

O Security Enhanced Linux (SELinux) é um sistema de controle de acesso obrigatório (MAC) para o sistema operacional Linux. Como um sistema MAC, ele é diferente do Linux de controle de acesso discricionário (DAC, na sigla em inglês). Em um sistema DAC, um conceito de propriedade, em que o proprietário de um recurso controla o acesso permissões associadas a ele. Geralmente, eles são de baixa granularidade e estão sujeitos para um escalonamento não intencional de privilégios. Um sistema MAC, no entanto, consulta um sistema autoridade para uma decisão sobre todas as tentativas de acesso.

O SELinux foi implementado como parte do Módulo de Segurança do Linux (LSM) que reconhece vários objetos do kernel e ações sensíveis realizada neles. No momento em que cada uma dessas ações seria executada, uma função de gancho do LSM é chamada para determinar se o deve ser permitida com base nas informações armazenadas em um formato objeto de segurança. O SELinux fornece uma implementação para esses hooks e gerenciamento desses objetos de segurança, que combinam com uma política própria para e determina as decisões de acesso.

Junto com outras medidas de segurança, o controle de acesso do Android limita muito os possíveis danos de máquinas comprometidas e contas de serviço. Usar ferramentas como o acesso discricionário e obrigatório do Android oferece uma estrutura para garantir que seu software seja executado apenas no mínimo nível de privilégio mínimo. Isso reduz os efeitos dos ataques e probabilidade de processos errôneos substituirem ou até mesmo transmitirem dados.

No Android 4.3 e versões mais recentes, o SELinux oferece um controle de acesso obrigatório (MAC) geral sobre ambientes de controle de acesso discricionário (DAC, na sigla em inglês) tradicionais. Para exemplo, o software precisa ser executado como a conta de usuário raiz para gravar em dados brutos dispositivos em bloco. Em um ambiente Linux tradicional baseado em DAC, se o usuário raiz fica comprometido, permitindo que o usuário grave em todos os dispositivos de bloco bruto. No entanto, O SELinux pode ser usado para rotular esses dispositivos, de modo que o processo privilégio só pode gravar nos especificados na política associada. Neste o processo não substitui os dados e as configurações do sistema fora da um dispositivo de bloco bruto específico.

Consulte Casos de uso. para mais exemplos de ameaças e maneiras de enfrentá-las com o SELinux.

Níveis de restrição

O SELinux pode ser implementado em modos variados:

• Permissivo: a política de segurança do SELinux não é aplicada, apenas registrada.
• Aplicação: a política de segurança é aplicada e registrada. Falhas aparecem como erros EPERM.

Essa escolha é binária e determina se a política será executada ou apenas para coletar possíveis falhas. A permissão permissiva é especialmente útil durante implementação.

Tipos, atributos e regras

O Android depende do componente de aplicação de tipo (TE) do SELinux para sua política. Isso significa que todos os objetos (como arquivo, processo ou soquete) têm uma type associado a elas. Por exemplo, por padrão, um app terão o tipo untrusted_app. Para um processo, seu tipo também é conhecido como domínio. É possível anotar um tipo com um ou muitos atributos. Os atributos são úteis para se referir a vários tipos ao mesmo tempo.

Os objetos são mapeados para classes (por exemplo, um arquivo, um diretório, um link simbólico, um soquete) e os diferentes tipos de acesso para cada classe são representadas por permissões. Por exemplo, a permissão open existe para a classe file. Embora os tipos e atributos sejam atualizados regularmente como parte a política do SELinux do Android, as permissões e as classes são definidas estaticamente e atualizado raramente como parte de uma nova versão do Linux.

Uma regra de política tem o seguinte formato: allow source target:class permissions; em que:

• Origem: o tipo (ou atributo) do assunto da regra. Quem está solicitando o acesso?
• Destino: o tipo (ou atributo) do objeto. A que acesso é solicitado?
• Classe: o tipo de objeto (por exemplo, arquivo, soquete) que está sendo acessado.
• Permissões: a operação (ou conjunto de operações) que está sendo executada, por exemplo, leitura ou gravação.

Um exemplo de regra é:

allow untrusted_app app_data_file:file { read write };

Isso diz que os aplicativos têm permissão para ler e gravar arquivos rotulados app_data_file: Existem outros tipos de apps. Para instâncias, isolated_app é usado para serviços de app com isolatedProcess=true no manifesto. Em vez de repetir para os dois tipos, o Android usa um atributo chamado appdomain para todos os tipos que abrangem aplicativos:

# Associate the attribute appdomain with the type untrusted_app.
typeattribute untrusted_app, appdomain;

# Associate the attribute appdomain with the type isolated_app.
typeattribute isolated_app, appdomain;

allow appdomain app_data_file:file { read write };

Quando uma regra que especifica um nome de atributo é escrita, esse nome é aberta automaticamente para a lista de domínios ou tipos associados . Alguns atributos importantes são:

• domain: atributo associado a todos os tipos de processos.
• file_type: atributo associado a todos os tipos de arquivo.

Macros

Para o acesso a arquivos em particular, há muitos tipos de permissão para considerar. Por exemplo, a permissão read não é suficiente para abrir o ou chamar stat nele. Para simplificar a definição de regras, o Android fornece um conjunto de macros para lidar com os casos mais comuns. Por exemplo, para para incluir as permissões ausentes, como open, a regra acima poderia ser reescrito como:

allow appdomain app_data_file:file rw_file_perms;

Consulte o global_macros e te_macros para ver mais exemplos de macros úteis. Use macros sempre que possível para ajudar a reduzir a probabilidade de falhas devido a negações em permissões.

Depois que um tipo é definido, ele precisa ser associado ao arquivo ou processo que ele representa. Consulte Como implementar o SELinux para mais detalhes sobre como essa associação é feita. Para mais informações sobre regras, consulte a Notebook SELinux.

Contexto e Categorias de Segurança

Ao depurar políticas do SELinux ou rotular arquivos (via file_contexts ou ao ls -Z), participe em um contexto de segurança (também conhecido como rótulo). Para exemplo: u:r:untrusted_app:s0:c15,c256,c513,c768: Um contexto de segurança tem o seguinte formato: user:role:type:sensitivity[:categories]: Em geral, você pode ignorar o Os campos user, role e sensitivity de um contexto (consulte Especificidade). O type é explicado na seção anterior. categories fazem parte de o curso Multi-Level Security (MLS) no SELinux. Desde o Android S, as categorias são usadas para:

• Isolar os dados do app do acesso de outro app.
• Isolar os dados do app de um usuário físico para outro.

Especificidade

O Android não usa todos os recursos fornecidos pelo SELinux. Durante a leitura documentação externa, lembre-se destes pontos:

• A maioria das políticas no AOSP é definida usando a linguagem de política do kernel. Há algumas exceções para o uso da Linguagem Intermediária Comum (CIL, na sigla em inglês).
• Os usuários do SELinux não são usados. O único definido pelo usuário u Quando necessário, os usuários físicos são representados pelo campo de categorias de um contexto de segurança.
• Os papéis do SELinux e o controle de acesso baseado em função (RBAC, na sigla em inglês) não são usados. Dois papéis padrão são definidos e usados: r para assuntos e object_r para objetos.
• As sensibilidades do SELinux não são usadas. A sensibilidade s0 padrão é sempre definida.
• Os booleanos do SELinux não são usados. Depois que a política é criada para um dispositivo, não depende do estado do dispositivo. Isso simplifica a auditoria e depuração de políticas.