据我了解，Linux 安全模块（LSM）框架有许多钩子，它们是安全模块的回调，用于注册在安全敏感操作之前执行额外安全检查的函数。
大多数时候，这些钩子被放置在访问内部数据结构（如file.
我不明白的一件事是为什么 System V IPC API 中有钩子，但相应的 POSIX API 中没有。例如，有security_ipc_permission一个钩子被描述include/linux/lsm_hooks.h为“影响所有 System V IPC 操作”，还有几个专门针对每个 API（例如消息队列）的钩子，但没有与 POSIX API 对应的钩子。手动调查显示，POSIX 函数中未使用 System V 挂钩（正如预期的那样，给出了描述）。但以 POSIX 消息队列和 System V 消息队列为例，虽然它们没有相同的接口，但它们提供了大致相同的功能。
所以我的问题是：不在 POSIX 函数中放置 LSM 挂钩的理由是什么？
答案1
我应该早点发布这个内容，但我在 2016 年 7 月的 LSM 邮件列表对话中得到了 SELinux 开发者和维护者 Stephen Smalley 的一些回答。由于该时期的原因，该邮件列表不再有存档。 MARC 停止归档该邮件列表，Gmane 停业，但我能够从我的备份中找到这封电子邮件：
[洛朗·乔治：]
你好，
本系列在一些系统调用中添加了LSM钩子。我建议将它们作为 RFC，因为我无法理解为什么这些 LSM 挂钩尚未存在，但也许有一个很好的理由，我想听听。
第一个补丁在 mq_timedsend 和 mq_timedreceive 中添加了挂钩。 mq_timedsend 和 mq_timedreceive 是用于操作 POSIX 消息队列的两个系统调用。尽管它们对应的 SysV 对应项 msgrcv 和 msgsnd 有 LSM 挂钩，但 mq_timedsend 和 mq_timedreceive 没有。
第二个补丁在系统调用 vmsplice、splice 和 tee 中添加了对 security_file_permission 的调用，并添加了新的 LSM 挂钩 security_splice_pipe_to_pipe。这三个系统调用利用 Linux 内核中管道的内部实现来执行管道之间或管道与文件之间的零复制数据传输。尽管从概念上讲，vmsplice、splice 或 tee 完成的任何操作都可以通过读取和写入序列（确实具有 LSM 挂钩）来执行，但这三个系统调用中没有对 LSM 挂钩的调用。
[史蒂芬·斯莫利：]
我认为它是以下各项的组合：
这些系统调用是在引入 LSM 后添加的，因此不是原始分析和检测的一部分，
由于 POSIX mqueues 是通过伪文件系统实现的，所以至少部分地被现有的基于文件的访问控制所覆盖，因此尚不清楚我们实际上是否需要任何额外的钩子，
splice() 期间对非管道文件的访问重新验证已由 rw_verify_area() 调用 security_file_permission() IIUC 涵盖。重新验证支持主要是支持在重新标记或策略更改时撤销对文件的访问权限。
并不是说你提出新的钩子是错误的，但以上内容可能有助于提供背景信息。
关于重新验证部分：
[洛朗·乔治：]
所以你的论点是管道不像常规文件那样需要重新验证，因此在打开成功后不需要验证？这是有道理的，但如果这是安全模块开发人员之间的普遍共识，则意味着信息流控制不是预期可以通过 LSM 实现的。
[史蒂芬·斯莫利：]
不，我一般不会争论这一点。迄今为止，这还不是一个主要问题。所以我并不反对添加钩子，尽管我认为我们可能也应该有一个用于管道创建的钩子，以便我们可以像打开文件一样缓存信息。即使对于文件，我们也存在其他重新验证问题，例如内存映射文件或异步 I/O。
因此，这就是 POSIX 消息队列中没有钩子的原因（根据 Stephen Smalley 的说法）。
LSM 是在 POSIX 消息队列之前实现的。
消息队列已经受益于 inode 上的挂钩。例如，要打开消息队列，您必须通过钩子
security_inode_open。read单独和类似操作中的钩子write仅用于重新验证，而重新验证对于常规文件最有用，这些文件是信息的永久存储（此参数适用于消息队列以及其他奇怪的情况，例如拼接）。