LSM是Linux Secrity Module的簡稱，即linux安全模塊。其是一種輕量級通用訪問控制框架，適合於多種訪問控制模型在它上面以內核可加載模塊的形實現。用戶可以根據自己的需求選擇合適的安全模塊加載到內核上實現。
LSM設計思想：
LSM的設計思想：在最少改變內核代碼的情況下，提供一個能夠成功實現強制訪問控制模塊需要的結構或者接口。LSM避免了利用如在systrace系統調用中的出現過的系統調用干預，因爲它不能擴展到多處理器內核，並且它受制於參數替換攻擊。還有LSM在設計時做了兩點考慮：對不使用的人來說盡量少引入麻煩，對使用的人來說要帶來效率。以Linus Torvalds爲代表的內核開發人員對Linux安全模塊（LSM）提出了三點要求：
1、真正的通用，當使用一個不同的安全模型的時候，只需要加載一個不同的內核模塊。
2、概念上簡單，對Linux內核影響最小，高效，並且。
3、能夠支持現存的POSIX.1e capabilities邏輯，作爲一個可選的安全模塊。
還有，針對linux上提出的各種不同的Linux安全增強系統對Linux安全模塊（LSM）提出的要求是：能夠允許他們以可加載內核模塊的形式重新實現其安全功能，並且不會在安全性方面帶來明顯的損失，也不會帶來額外的系統開銷。
LSM框架結構：
LSM框架主要由五部分構成：
1、在特定的內核數據結構中加入安全域。
2、在內核源代碼中不同的關鍵點插入對安全鉤子函數的調用。
3、加入一個通用的安全系統調用。
4、提供了函數允許內核模塊註冊爲安全模塊或者註銷。
5、5、將capabilities邏輯的大部分移植爲一個可選的安全模塊。
安全域是一個void*類型的指針，它使得安全模塊把安全信息和內核內部對象聯繫起來。下面列出被修改加入了安全域的內核數據結構，以及各自所代表的內核內部對象：
-
task_struct結構：代表任務（進程）
-
linux_binprm結構：代表程序
-
super_block結構：代表文件系統
-
inode結構：代表管道，文件，或者Socket套接字
-
file結構：代表打開的文件
-
sk_buff結構：代表網絡緩衝區（包）
-
net_device結構：代表網絡設備
-
kern_ipc_perm結構：代表Semaphore信號，共享內存段，或者消息隊列
-
msg_msg：代表單個的消息
Linux安全模塊（LSM）提供了兩類對安全鉤子函數的調用：一類管理內核對象的安全域，另一類仲裁對這些內核對象的訪問。對安全鉤子函數的調用通過鉤子來實現，鉤子是全局表security_ops中的函數指針，這個全局表的類型是security_operations結構，這個結構定義在include/linux/security.h這個頭文件中。
LSM接口的核心是security_ops，當系統啓動時，他們被初始化爲傳統的DAC策略。傳統DAC訪問控制是指控制系統中的主體（如進程）對系統中的客體（如文件目錄、文件）的訪問（讀、寫和執行等）。自主訪問控制DAC 是指主體（進程，用戶）對客體（文件、目錄、特殊設備文件、IPC等）的訪問權限是由客體的屬主或超級用戶決定的，而且此權限一旦確定，將作爲以後判斷主體對客體是否有訪問權限的依據。
在加載安全模塊時，我們必需先對模塊進行註冊，我們可以使用register_security()函數向ＬＳＭ註冊一個安全模塊。在我們的模塊被加載成功後，就可以進行訪問控制操作。如果此時還有一個安全模塊要使用register_security()函數進行加載，則會出現錯誤，直到使用unregister_security()函數向框架註銷後，下一個模塊纔可以載入。當然ＬＳＭ還提供了mod_reg_security()函數和mod_unreg_security()函數，可以連續註冊多個安全模塊。如果有其他後來的模塊需要載入，可以通過mod_reg_security（）向第一個模塊註冊，形成支持不同策略的模塊棧。
注：以上出現的函數均基於2.6.22以前的版本，對於後續的版本，出現了register_security()函數未被導出或者取消掉了unregister_security()函數。
LSM執行過程：
根據下圖的執行步驟：用戶在執行系統調用時，先通過原有的內核接口依次執行功能性的錯誤檢查，接着進行傳統的DAC檢查，並在即將訪問內核的內部對象之前，通過LSM鉤子函數調用LSM。LSM再調用具體的訪問控制策略來決定訪問的合法性。圖三顯示了ＬＳＭ鉤子的調用：
圖三：基於LSM的內核對象訪問過程
Lilinux安全模塊（LSM）主要支持"限制型"的訪問控制決策：當Linux內核授予文件或目錄訪問權限時，Linux安全模塊（LSM）可能會拒絕，而當 Linux內核拒絕訪問時，可以跳過LSM。