Que funções DAC (permissões de arquivo), ACL e MAC (SELinux) desempenham na segurança de arquivos do Linux?

Question

Eu preciso de esclarecimento / confirmação / elaboração sobre as diferentes funções que o DAC, ACL e MAC desempenham na segurança de arquivos do Linux.

Após algumas pesquisas da documentação, este é o meu entendimento da pilha:

1. O SELinux deve permitir o acesso ao objeto de arquivo.
2. Se as ACLs do arquivo (por exemplo, setfacl , getfacl para uma montagem de ACL) permitirem / negarem acesso ao objeto explicitamente, nenhum processamento adicional será necessário.
3. Caso contrário, cabe às permissões do arquivo (modelo DAC rwxrwxrwx).

Estou faltando alguma coisa? Existem situações em que isso não é o caso?

    

Answer 1

Quando um processo executa uma operação em um arquivo, o kernel do Linux executa a verificação na seguinte ordem:

1. Controle de Acesso Discricionário (DAC) ou controle de acesso ditado pelo usuário. Isso inclui as verificações de permissão clássicas do estilo UNIX e as Listas de Controle de Acesso POSIX (ACL) . As verificações clássicas do UNIX comparam o UID e o GID do processo atual com o UID e o GID do arquivo que está sendo acessado em relação a quais modos foram definidos (Read / Write / eXecute). A Lista de Controle de Acesso estende as verificações clássicas do UNIX para permitir mais opções com relação ao controle de permissão.

2. Controle de acesso obrigatório (MAC) ou controle de acesso baseado em políticas. Isso é implementado usando Módulos de segurança do Linux (LSM) que não são mais módulos reais (eles costumavam ser, mas foram descartados) . Eles permitem verificações adicionais com base em outros modelos além das verificações de segurança clássicas do estilo UNIX. Todos esses modelos são baseados em uma política descrevendo que tipo de operações são permitidas para qual processo em qual contexto.

Aqui está um exemplo de acesso de inodes (que inclui acesso a arquivos) para retornar minha resposta com links para uma Referência Cruzada . O " function_name (filename: line)" dado é para a versão 3.14 do kernel Linux.

A função inode_permission ( fs / namei.c: 449 ) primeiro verifica a permissão de leitura no próprio sistema de arquivos ( sb_permission em fs /namei.c:425 ), depois chama __inode_permission ( fs / namei.c: 394 ) para verificar permissões de leitura / gravação / execução e POSIX ACL em um inode em do_inode_permission (fs/namei.c:368 ) (DAC) e, em seguida, permissões relacionadas ao LSM (MAC) em security_inode_permission (security/security.c:550 ).

Houve apenas uma exceção para este pedido (DAC e MAC): foi para as verificações do mmap. Mas isso foi corrigido na versão 3.15 do kernel do Linux ( commit relevante ).

    

Answer 2

DAC == Discretionary Access Control , link
MAC == Mandatory Access Control , < href="http://en.wikipedia.org/wiki/Mandatory_access_control"> link
ACL == Access Control List , link

O ACL especifica os controles a serem aplicados pelo método de controle, DAC ou MAC . MAC é explícito, controlado centralmente e não permite que usuários concedam autoridade a um objeto, a menos que tenham permissões explícitas para fazer isso, enquanto DAC permite que usuários concedam a outros usuários acesso a objetos que podem acessar.

MAC ACL s sempre será aplicado a uma solicitação primeiro e, se o acesso for negado, o processamento será interrompido. Se o acesso for permitido, o DAC ACL s será aplicado e, novamente, se o acesso for negado, o processamento será interrompido. Somente se o acesso for concedido por MAC e DAC ACL s, o usuário poderá acessar o objeto solicitado.

SELinux é uma implementação de MAC para o Linux (há outros), enquanto as permissões tradicionais do arquivo rwx , combinadas com o usuário e grupo proprietários, formam o total DAC ACL . A política SELinux 'é essencialmente a MAC ACL .

    

Answer 3

Desculpe questionar, mas acho que algumas das respostas aqui podem estar incorretas. Diretamente do link do Fedora :

SELinux policy rules are checked after DAC rules. SELinux policy rules are not used if DAC rules deny access first.