Conceitos do SELinux

Consulte esta página para conhecer 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 sistema de controle de acesso discricionário (DAC) do Linux. Em um sistema DAC, existe um conceito de propriedade em que o proprietário de um recurso específico controla as permissões de acesso associadas a ele. Isso geralmente é de granularidade grosseira e está sujeito a escalonamento de privilégios não intencional. Um sistema MAC, no entanto, consulta uma autoridade central para tomar uma decisão sobre todas as tentativas de acesso.

O SELinux foi implementado como parte da estrutura do módulo de segurança do Linux (LSM, na sigla em inglês), que reconhece vários objetos do kernel e ações sensíveis realizadas neles. No momento em que cada uma dessas ações seria realizada, uma função de hook do LSM é chamada para determinar se a ação deve ser permitida com base nas informações armazenadas em um objeto de segurança opaco. O SELinux oferece uma implementação para esses hooks e o gerenciamento desses objetos de segurança, que se combinam com a própria política para determinar as decisões de acesso.

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

No Android 4.3 e versões mais recentes, o SELinux oferece um controle de acesso obrigatório (MAC) em ambientes tradicionais de controle de acesso discricionário (DAC). Por exemplo, o software geralmente precisa ser executado como a conta de usuário raiz para gravar em dispositivos de bloco brutos. Em um ambiente Linux tradicional baseado em DAC, se o usuário root for comprometido, ele poderá gravar em todos os dispositivos de bloco brutos. No entanto, o SELinux pode ser usado para rotular esses dispositivos para que o processo atribuído ao privilégio de raiz possa gravar apenas aqueles especificados na política associada. Assim, o processo não pode substituir dados e configurações do sistema fora do dispositivo de bloco bruto específico.

Consulte Casos de uso para mais exemplos de ameaças e maneiras de lidar com elas usando o SELinux.

Níveis de restrição

O SELinux pode ser implementado em vários modos:

• 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. As falhas aparecem como erros EPERM.

Essa escolha é binária e determina se a política vai tomar uma ação ou apenas permitir que você colete possíveis falhas. O modo permissivo é especialmente útil durante a implementação.

Tipos, atributos e regras

O Android depende do componente de imposição de tipo (TE, na sigla em inglês) do SELinux para a política. Isso significa que todos os objetos (como arquivo, processo ou soquete) têm um tipo associado a eles. Por exemplo, por padrão, um app tem o tipo untrusted_app. Para um processo, o tipo também é conhecido como domínio. É possível anotar um tipo com um ou vários 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 representados por permissões. Por exemplo, a permissão open existe para a classe file. Embora os tipos e atributos sejam atualizados regularmente como parte da política do SELinux do Android, as permissões e classes são definidas de forma estática e raramente atualizadas como parte de um novo lançamento do Linux.

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

• Origem: o tipo (ou atributo) do assunto da regra. Quem está pedindo o acesso?
• Destino: o tipo (ou atributo) do objeto. Para o que o acesso foi 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 realizada (por exemplo, leitura ou gravação).

Exemplo de uma regra:

allow untrusted_app app_data_file:file { read write };

Isso significa que os apps podem ler e gravar arquivos marcados como app_data_file. Existem outros tipos para apps. Por exemplo, isolated_app é usado para serviços de apps com isolatedProcess=true no manifesto. Em vez de repetir a regra para os dois tipos, o Android usa um atributo chamado appdomain para todos os tipos que abrangem apps:

# 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 é escrita especificando um nome de atributo, esse nome é expandido automaticamente para a lista de domínios ou tipos associados ao atributo. Alguns atributos importantes são:

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

Macros

Para acesso a arquivos, em particular, há muitos tipos de permissões a serem consideradas. Por exemplo, a permissão read não é suficiente para abrir o arquivo 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 incluir as permissões ausentes, como open, a regra acima pode ser reescrita como:

allow appdomain app_data_file:file rw_file_perms;

Consulte os arquivos global_macros e te_macros para mais exemplos de macros úteis. As macros devem ser usadas sempre que possível para reduzir a probabilidade de falhas devido a negações de permissões relacionadas.

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

Contexto e categorias de segurança

Ao depurar políticas do SELinux ou rotular arquivos (usando file_contexts ou ls -Z), você pode encontrar um contexto de segurança (também conhecido como rótulo). Por exemplo: u:r:untrusted_app:s0:c15,c256,c513,c768. Um contexto de segurança tem o formato: user:role:type:sensitivity[:categories]. Geralmente, é possível ignorar os campos user, role e sensitivity de um contexto (consulte Especificidade). O campo type é explicado na seção anterior. categories fazem parte do suporte à segurança multinível (MLS, na sigla em inglês) no SELinux. No Android 12 e versões mais recentes, 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. Ao ler 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 Common Intermediate Language (CIL).
• Os usuários do SELinux não são usados. O único usuário definido é u. Quando necessário, os usuários físicos são representados usando o campo "categorias" de um contexto de segurança.
• As funções do SELinux e o controle de acesso baseado em papéis (RBAC) não são usados. Dois papéis padrão são definidos e usados: r para sujeitos e object_r para objetos.
• As sensibilidades do SELinux não são usadas. A sensibilidade padrão do s0 está sempre definida.
• As booleanas do SELinux não são usadas. Quando a política é criada para um dispositivo, ela não depende do estado dele. Isso simplifica a auditoria e a depuração das políticas.