Por que não há ganchos de LSM nas APIs POSC IPC?

Question

Pelo que entendi, a estrutura Linux Security Module (LSM) tem muitos ganchos que são retornos de chamada para módulos de segurança para registrar funções que executam verificações de segurança adicionais antes de operações sensíveis à segurança.

Na maioria das vezes, esses ganchos são colocados antes do acesso a uma estrutura de dados interna, como file .

Uma coisa que não entendo é por que há ganchos nas APIs IP do System V, mas não nas APIs POSIX correspondentes. Por exemplo, há security_ipc_permission , que é um gancho descrito em include/linux/lsm_hooks.h como "afetando todas as operações do System V IPC" e vários outros ganchos especializados para cada API, como as filas de mensagens, mas sem contrapartida para as APIs POSIX. A investigação manual revela que os ganchos do System V não são usados nas funções POSIX (como esperado, dada a descrição). Mas, no caso de filas de mensagens POSIX e filas de mensagens do System V, por exemplo, embora não tenham a mesma interface, elas fornecem aproximadamente a mesma funcionalidade.

Então, minha pergunta é: qual é a razão para não colocar ganchos do LSM em funções POSIX?

    

Answer 1

Eu deveria ter postado isso antes, mas recebi alguns elementos de resposta de Stephen Smalley, desenvolvedor e mantenedor do SELinux, em uma conversa na lista de discussão do LSM, em julho de 2016. Não há mais um arquivo para esta lista de discussão período, devido a MARC parar de arquivar essa lista de discussão e Gmane sair do negócio, mas eu era capaz de desenterrar este e-mail de meus backups:

[Laurent Georget:]

Hi,

this series adds LSM hooks in some system calls. I propose them as a RFC because I fail to understand why these LSM hooks are not already present but maybe there is a very good reason, and I'd like to hear it.

The first patch adds hooks in mq_timedsend and mq_timedreceive. mq_timedsend and mq_timedreceive are the two system calls used to manipulate POSIX message queues. Although their corresponding SysV counterparts msgrcv and msgsnd have LSM hooks, mq_timedsend and mq_timedreceive have not.

The second patch adds calls to the security_file_permission in system calls vmsplice, splice and tee, and adds a new LSM hook security_splice_pipe_to_pipe. These three system calls leverage the internal implementation of pipes in the Linux kernel to perform zero-copy data transfer between pipes, or between a pipe and a file. Although conceptually, any operation done by vmsplice, splice or tee could be performed by sequences of read and write (which do have LSM hooks), there are no calls to LSM hooks in these three system calls.

     

[Stephen Smalley:]

     

Eu acho que é uma combinação de:

     

• essas chamadas do sistema foram adicionadas após a introdução do LSM e, portanto, não faziam parte da análise e instrumentação originais,

  

• As linhas de espera do POSIX são pelo menos parcialmente cobertas pelos controles de acesso existentes baseados em arquivos, devido a serem implementadas por meio de um pseudo sistema de arquivos e   portanto, não está claro se de fato precisamos de ganchos adicionais,

  

• A revalidação do acesso a arquivos não-pipe durante splice () já é coberta por rw_verify_area () chamando security_file_permission () IIUC.   E o apoio à revalidação é principalmente para apoiar a revogação de   acesso a arquivos mediante nova etiquetagem ou mudança de política.

  

Não está dizendo que você está errado em propor novos ganchos, mas o acima pode   ajudar a fornecer contexto.

Sobre a parte de revalidação:

[Laurent Georget:]

So your argument would be that pipes are not subject to revalidation like regular files, and as such, no validation is necessary after their opening succeeds? This makes sense but if this is the general consensus among the security modules developers, this means that information flow control is not something which is expected to be implementable with LSM.

     

[Stephen Smalley:]

     

Não, eu não diria que em geral; só não tem sido um grande   preocupação até à data. Então eu não sou contra adicionar ganchos, embora eu pense   nós provavelmente deveríamos ter um para a criação de tubos também para que possamos   armazenar em cache as informações da mesma maneira que fazemos para o arquivo aberto. Nós   também tem outros problemas para revalidação mesmo para arquivos, por exemplo para   arquivos mapeados na memória ou i / o assíncrono.

Então, aqui estão as razões pelas quais não há ganchos nas filas de mensagens POSIX (de acordo com Stephen Smalley).

• O LSM foi implementado antes das filas de mensagens POSIX.

• As filas de mensagens já se beneficiam dos ganchos nos inodes. Por exemplo, para abrir uma fila de mensagens, você teria que passar pelo security_inode_open hook.

• Ganchos em operações read e write -like individuais são fornecidos apenas para revalidação, e a revalidação é mais útil para arquivos regulares, que são armazenamento permanente de informações (esse argumento aplica-se a filas de mensagens e outros casos estranhos como splice).