為什麼 POSIX IPC API 中沒有 LSM 掛鉤？
據我了解，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 鉤子的理由是什麼？
我應該早點發布的，但我從 SELinux 開發人員和維護人員 Stephen Smalley 那裡得到了一些答案，在 2016 年 7 月 LSM 郵件列表上的一次對話中。那個時期的郵件列表不再有存檔，因為到 MARC 停止歸檔該郵件列表和 Gmane 倒閉，但我能夠從我的備份中挖出這封電子郵件：
> > $$ Laurent Georget: $$ > 你好， > > > 本系列在一些系統呼叫中添加了 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 掛鉤的呼叫。 > > >
$$ Stephen Smalley: $$ 我認為這是一個組合：
- 這些系統呼叫是在引入 LSM 之後添加的，因此不是原始分析和檢測的一部分，
- 由於是通過偽文件系統實現的，POSIX mqueue 至少部分被現有的基於文件的訪問控制所覆蓋，因此不清楚我們實際上是否需要任何額外的鉤子，
- rw_verify_area() 呼叫 security_file_permission() IIUC 已經涵蓋了在 splice() 期間重新驗證對非管道文件的訪問。重新驗證支持主要是支持在重新標記或策略更改時撤銷對文件的訪問。
並不是說你提出新的鉤子是錯誤的，但以上內容可能有助於提供上下文。
關於重新驗證部分：
> > $$ Laurent Georget: $$ > 所以你的論點是管道不像正常文件那樣需要重新驗證，因此在打開成功後不需要驗證？這是有道理的，但如果這是安全模組開發人員之間的普遍共識，這意味著資訊流控制不是預期可以通過 LSM 實現的。 > > >
$$ Stephen Smalley: $$ 不，我一般不會這麼說。迄今為止，這還不是主要問題。所以我不反對添加鉤子，儘管我認為我們可能也應該有一個用於創建管道的鉤子，以便我們可以以與打開文件相同的方式記憶體資訊。即使對於文件，我們也有其他問題，例如記憶體映射文件或非同步 i/o。
因此，這就是 POSIX 消息隊列中沒有鉤子的原因（根據 Stephen Smalley 的說法）。
- LSM 是在 POSIX 消息隊列之前實現的。
- 消息隊列已經受益於 inode 上的掛鉤。例如，要打開一個消息隊列，您必須通過
security_inode_open鉤子。read單獨和類似操作中的鉤子write僅用於重新驗證，重新驗證主要用於正常文件，它們是資訊的永久儲存（此參數適用於消息隊列以及其他奇怪的情況，如拼接）。