I should have posted that earlier but I got some elements of answer from Stephen Smalley, SELinux developper and maintainer, in a conversation on the LSM mailing list, in July 2016. There is no longer an archive for this mailing list for that period, due to MARC stopping archiving that mailing list and Gmane going out of business but I was able to dug up this email from my 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:]
I think it is a combination of:
these system calls were added after LSM was introduced and thus were not part of the original analysis and instrumentation,
POSIX mqueues are at least partly covered by the existing file-based access controls due to being implemented via a pseudo filesystem and therefore it is unclear if we in fact need any additional hooks,
Revalidation of access to non-pipe files during splice() is already covered by rw_verify_area() calling security_file_permission() IIUC. And revalidation support is principally to support revocation of access to files upon relabeling or policy change.
Not saying that you are wrong to propose new hooks, but the above may help provide context.
About the revalidation part:
[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:]
No, I wouldn't argue that in general; it just hasn't been a major concern to date. So I'm not opposed to adding hooks, although I think we probably ought to have one for pipe creation too so that we can cache the information in the same manner that we do for file open. We also have other problems wrt revalidation even for files, e.g. for memory-mapped files or async i/o.
So, here are the reasons why there are no hooks in POSIX message queues (according to Stephen Smalley).
LSM was implemented before POSIX message queues.
Message queues already benefit from the hooks on inodes. For example, to open a message queue, you would have to go through the security_inode_open hook.
Hooks in individual read and write-like operations are only provided for revalidation, and revalidation is mostly useful for regular files, which are permanent storage of information (this argument applies to message queues as well as other strange cases like splice).
