Documentation/security/lsm.rst

20 implemented as its own particular kernel patch. Several other security
25 patch to support its security needs.
28 remarks that described a security framework he would be willing to
30 general framework that would provide a set of security hooks to control
31 operations on kernel objects and a set of opaque security fields in
32 kernel data structures for maintaining security attributes. This
34 desired model of security. Linus also suggested the possibility of
38 such a framework. LSM was a joint development effort by several security
44 security module.
50 security modules. In particular, the LSM framework is primarily focused
52 likely to address other security needs such as sandboxing. By itself, the
53 framework does not provide any additional security; it merely provides
54 the infrastructure to support security modules. The LSM framework is
56 logic is implemented as a security module.
60 The LSM framework includes security fields in kernel data structures and
62 manage the security fields and to perform access control.
63 It also adds functions for registering security modules.
64 An interface `/sys/kernel/security/lsm` reports a comma separated list
65 of security modules that are active on the system.
67 The LSM security fields are simply ``void*`` pointers.
69 the framework or by the individual security modules that use it.
70 Security blobs that are used by more than one security module are
73 program execution security information, security fields are included in
77 security information, a security field is included in :c:type:`struct
78 super_block <super_block>`. For pipe, file, and socket security
79 information, security fields are included in :c:type:`struct inode
81 For System V IPC security information,
82 security fields were added to :c:type:`struct kern_ipc_perm
87 ``include/linux/shm.h`` as appropriate) to allow the security modules to
91 network device security information, security fields were added to
94 Unlike the other security module data, the data used here is a
95 32-bit integer. The security modules are required to map or otherwise
96 associate these values with real security attributes.
101 included in the `security/security.c` source file.
104 general security module stacking. It defines
105 security_add_hooks() to which each security module passes a
109 have been registered. The SELinux security module has implemented
113 categories: hooks that are used to manage the security fields and hooks
117 and free security structures for inode objects.
125 The POSIX.1e capabilities logic is maintained as a security module
126 stored in the file ``security/commoncap.c``. The capabilities
128 to identify it as the first security module to be registered.
129 The capabilities security module does not use the general security