É MAC ou DAC?

Question

Estou tendo problemas para ver o utilitário ou o uso das implementações de atributo / limites do LSM.

Eu montei um trecho de pseudo-código para tentar expressar minha preocupação e pergunta. É modelado após um diagrama de (p 3) link

Verificação de acesso ao kernel (aprox.) e chamada do LSM:

DAC
op:__?   // ? what operation would pass a DAC check yet not the LSM hook ?
file:___
perms:  u.. g.. o.. 
euid:100
egid:500


OK  ----> LSM hook ( args ) 

        1) I don't know the args here, 

        2) Regardless of the args I can't make out what operation would pass a DAC check
           and be restricted here and why? 

           ? read file ?      allready handled by DAC

           ? network device ? allready handled by DAC, it's a file.

           ? execution ?      x bit , allready handled

           ? executing a specific function ? no function call references here

           ? executing a specific syscall ? would be handled on exec on the target (read, write etc..)

           ?  
           **What exactly can the LSM hook accomplish here that DAC hasn't allready addressed ??**


            Answers are welcome.
            sp

Eu li falar sobre a tentativa de ter codificadores que não usam o setuid root e usam algum atributo CAP                em vez de fazer este trabalho para uma escalada privilegiada mais segura, mas eu estou pessoalmente                não é um especialista em confiar em uma mudança no comportamento nem uma verificação de permissões de gancho                para garantir a integridade do código em execução em uma máquina e duvido que esteja sozinho.

Eu também li que não é a intenção do LSM aqui

que aborda o design ainda permanece vago em usos precisos sobre as verificações atuais de permissões do DAC. Ele fala sobre por que os ganchos estão onde estão, mas não como usá-los efetivamente para, novamente, realizar algo mais do que o DAC.

    

Answer 1

Os recursos são uma camada de escalonamento de privilégios semelhante à setuid, mas muito mais refinada; Por exemplo, um programa pode obter privilégios CAP_NET_RAW sem ter acesso total ao nível da raiz. É um grande passo em frente para "privilégios mínimos necessários" e controle de um servidor, por isso é bom, mas não é um Controle de Acesso Obrigatório; é uma escalada de privilégios.

O SELinux funciona nos conceitos de rótulos e permissões entre rótulos. Portanto, você pode conceder ao processo httpd o rótulo "servidor da Web", todos os arquivos dentro da web o rótulo "arquivos da Web" e conceder "processos rotulados pelo servidor da Web podem ler arquivos da Web e nada mais".

Esta construção de rotulagem fica acima das permissões do sistema de arquivos e das permissões de ACL existentes. Mesmo se um arquivo for legível por todo o mundo, o SELinux poderá negar acesso a ele. Para que um processo receba acesso, ele precisa passar as permissões DAC (permissões do sistema de arquivos) e MAC (SELinux).

Do lado comercial do mundo, o eTrust Access Control (ou Control Minder, ou seja lá como ele é chamado atualmente; originalmente SEOS ) é outra camada MAC. Isso não usa rótulos para controlar o material, mas permite regras definidas pelo caminho e programas de soma de verificação, se forem usados em uma regra. Isso é mais flexível do que os rótulos do SELinux (e é multi-plataforma; por exemplo, Solaris, AIX, HPUX). Novamente, isso fica acima da camada DAC do sistema de arquivos; ambos precisam aprovar o pedido.