1========================================================
  2Linux Security Modules: General Security Hooks for Linux
  3========================================================
  4
  5:Author: Stephen Smalley
  6:Author: Timothy Fraser
  7:Author: Chris Vance
  8
  9.. note::
 10
 11   The APIs described in this book are outdated.
 12
 13Introduction
 14============
 15
 16In March 2001, the National Security Agency (NSA) gave a presentation
 17about Security-Enhanced Linux (SELinux) at the 2.5 Linux Kernel Summit.
 18SELinux is an implementation of flexible and fine-grained
 19nondiscretionary access controls in the Linux kernel, originally
 20implemented as its own particular kernel patch. Several other security
 21projects (e.g. RSBAC, Medusa) have also developed flexible access
 22control architectures for the Linux kernel, and various projects have
 23developed particular access control models for Linux (e.g. LIDS, DTE,
 24SubDomain). Each project has developed and maintained its own kernel
 25patch to support its security needs.
 26
 27In response to the NSA presentation, Linus Torvalds made a set of
 28remarks that described a security framework he would be willing to
 29consider for inclusion in the mainstream Linux kernel. He described a
 30general framework that would provide a set of security hooks to control
 31operations on kernel objects and a set of opaque security fields in
 32kernel data structures for maintaining security attributes. This
 33framework could then be used by loadable kernel modules to implement any
 34desired model of security. Linus also suggested the possibility of
 35migrating the Linux capabilities code into such a module.
 36
 37The Linux Security Modules (LSM) project was started by WireX to develop
 38such a framework. LSM was a joint development effort by several security
 39projects, including Immunix, SELinux, SGI and Janus, and several
 40individuals, including Greg Kroah-Hartman and James Morris, to develop a
 41Linux kernel patch that implements this framework. The work was
 42incorporated in the mainstream in December of 2003. This technical
 43report provides an overview of the framework and the capabilities
 44security module.
 45
 46LSM Framework
 47=============
 48
 49The LSM framework provides a general kernel framework to support
 50security modules. In particular, the LSM framework is primarily focused
 51on supporting access control modules, although future development is
 52likely to address other security needs such as sandboxing. By itself, the
 53framework does not provide any additional security; it merely provides
 54the infrastructure to support security modules. The LSM framework is
 55optional, requiring `CONFIG_SECURITY` to be enabled. The capabilities
 56logic is implemented as a security module.
 57This capabilities module is discussed further in
 58`LSM Capabilities Module`_.
 59
 60The LSM framework includes security fields in kernel data structures and
 61calls to hook functions at critical points in the kernel code to
 62manage the security fields and to perform access control.
 63It also adds functions for registering security modules.
 64An interface `/sys/kernel/security/lsm` reports a comma separated list
 65of security modules that are active on the system.
 66
 67The LSM security fields are simply ``void*`` pointers.
 68The data is referred to as a blob, which may be managed by
 69the framework or by the individual security modules that use it.
 70Security blobs that are used by more than one security module are
 71typically managed by the framework.
 72For process and
 73program execution security information, security fields are included in
 74:c:type:`struct task_struct <task_struct>` and
 75:c:type:`struct cred <cred>`.
 76For filesystem
 77security information, a security field is included in :c:type:`struct
 78super_block <super_block>`. For pipe, file, and socket security
 79information, security fields are included in :c:type:`struct inode
 80<inode>` and :c:type:`struct file <file>`.
 81For System V IPC security information,
 82security fields were added to :c:type:`struct kern_ipc_perm
 83<kern_ipc_perm>` and :c:type:`struct msg_msg
 84<msg_msg>`; additionally, the definitions for :c:type:`struct
 85msg_msg <msg_msg>`, struct msg_queue, and struct shmid_kernel
 86were moved to header files (``include/linux/msg.h`` and
 87``include/linux/shm.h`` as appropriate) to allow the security modules to
 88use these definitions.
 89
 90For packet and
 91network device security information, security fields were added to
 92:c:type:`struct sk_buff <sk_buff>` and
 93:c:type:`struct scm_cookie <scm_cookie>`.
 94Unlike the other security module data, the data used here is a
 9532-bit integer. The security modules are required to map or otherwise
 96associate these values with real security attributes.
 97
 98LSM hooks are maintained in lists. A list is maintained for each
 99hook, and the hooks are called in the order specified by CONFIG_LSM.
100Detailed documentation for each hook is
101included in the `security/security.c` source file.
102
103The LSM framework provides for a close approximation of
104general security module stacking. It defines
105security_add_hooks() to which each security module passes a
106:c:type:`struct security_hooks_list <security_hooks_list>`,
107which are added to the lists.
108The LSM framework does not provide a mechanism for removing hooks that
109have been registered. The SELinux security module has implemented
110a way to remove itself, however the feature has been deprecated.
111
112The hooks can be viewed as falling into two major
113categories: hooks that are used to manage the security fields and hooks
114that are used to perform access control. Examples of the first category
115of hooks include the security_inode_alloc() and security_inode_free()
116These hooks are used to allocate
117and free security structures for inode objects.
118An example of the second category of hooks
119is the security_inode_permission() hook.
120This hook checks permission when accessing an inode.
121
122LSM Capabilities Module
123=======================
124
125The POSIX.1e capabilities logic is maintained as a security module
126stored in the file ``security/commoncap.c``. The capabilities
127module uses the order field of the :c:type:`lsm_info` description
128to identify it as the first security module to be registered.
129The capabilities security module does not use the general security
130blobs, unlike other modules. The reasons are historical and are
131based on overhead, complexity and performance concerns.

  1========================================================
  2Linux Security Modules: General Security Hooks for Linux
  3========================================================
  4
  5:Author: Stephen Smalley
  6:Author: Timothy Fraser
  7:Author: Chris Vance
  8
  9.. note::
 10
 11   The APIs described in this book are outdated.
 12
 13Introduction
 14============
 15
 16In March 2001, the National Security Agency (NSA) gave a presentation
 17about Security-Enhanced Linux (SELinux) at the 2.5 Linux Kernel Summit.
 18SELinux is an implementation of flexible and fine-grained
 19nondiscretionary access controls in the Linux kernel, originally
 20implemented as its own particular kernel patch. Several other security
 21projects (e.g. RSBAC, Medusa) have also developed flexible access
 22control architectures for the Linux kernel, and various projects have
 23developed particular access control models for Linux (e.g. LIDS, DTE,
 24SubDomain). Each project has developed and maintained its own kernel
 25patch to support its security needs.
 26
 27In response to the NSA presentation, Linus Torvalds made a set of
 28remarks that described a security framework he would be willing to
 29consider for inclusion in the mainstream Linux kernel. He described a
 30general framework that would provide a set of security hooks to control
 31operations on kernel objects and a set of opaque security fields in
 32kernel data structures for maintaining security attributes. This
 33framework could then be used by loadable kernel modules to implement any
 34desired model of security. Linus also suggested the possibility of
 35migrating the Linux capabilities code into such a module.
 36
 37The Linux Security Modules (LSM) project was started by WireX to develop
 38such a framework. LSM was a joint development effort by several security
 39projects, including Immunix, SELinux, SGI and Janus, and several
 40individuals, including Greg Kroah-Hartman and James Morris, to develop a
 41Linux kernel patch that implements this framework. The work was
 42incorporated in the mainstream in December of 2003. This technical
 43report provides an overview of the framework and the capabilities
 44security module.
 45
 46LSM Framework
 47=============
 48
 49The LSM framework provides a general kernel framework to support
 50security modules. In particular, the LSM framework is primarily focused
 51on supporting access control modules, although future development is
 52likely to address other security needs such as sandboxing. By itself, the
 53framework does not provide any additional security; it merely provides
 54the infrastructure to support security modules. The LSM framework is
 55optional, requiring `CONFIG_SECURITY` to be enabled. The capabilities
 56logic is implemented as a security module.
 57This capabilities module is discussed further in
 58`LSM Capabilities Module`_.
 59
 60The LSM framework includes security fields in kernel data structures and
 61calls to hook functions at critical points in the kernel code to
 62manage the security fields and to perform access control.
 63It also adds functions for registering security modules.
 64An interface `/sys/kernel/security/lsm` reports a comma separated list
 65of security modules that are active on the system.
 66
 67The LSM security fields are simply ``void*`` pointers.
 68The data is referred to as a blob, which may be managed by
 69the framework or by the individual security modules that use it.
 70Security blobs that are used by more than one security module are
 71typically managed by the framework.
 72For process and
 73program execution security information, security fields are included in
 74:c:type:`struct task_struct <task_struct>` and
 75:c:type:`struct cred <cred>`.
 76For filesystem
 77security information, a security field is included in :c:type:`struct
 78super_block <super_block>`. For pipe, file, and socket security
 79information, security fields are included in :c:type:`struct inode
 80<inode>` and :c:type:`struct file <file>`.
 81For System V IPC security information,
 82security fields were added to :c:type:`struct kern_ipc_perm
 83<kern_ipc_perm>` and :c:type:`struct msg_msg
 84<msg_msg>`; additionally, the definitions for :c:type:`struct
 85msg_msg <msg_msg>`, struct msg_queue, and struct shmid_kernel
 86were moved to header files (``include/linux/msg.h`` and
 87``include/linux/shm.h`` as appropriate) to allow the security modules to
 88use these definitions.
 89
 90For packet and
 91network device security information, security fields were added to
 92:c:type:`struct sk_buff <sk_buff>` and
 93:c:type:`struct scm_cookie <scm_cookie>`.
 94Unlike the other security module data, the data used here is a
 9532-bit integer. The security modules are required to map or otherwise
 96associate these values with real security attributes.
 97
 98LSM hooks are maintained in lists. A list is maintained for each
 99hook, and the hooks are called in the order specified by CONFIG_LSM.
100Detailed documentation for each hook is
101included in the `include/linux/lsm_hooks.h` header file.
102
103The LSM framework provides for a close approximation of
104general security module stacking. It defines
105security_add_hooks() to which each security module passes a
106:c:type:`struct security_hooks_list <security_hooks_list>`,
107which are added to the lists.
108The LSM framework does not provide a mechanism for removing hooks that
109have been registered. The SELinux security module has implemented
110a way to remove itself, however the feature has been deprecated.
111
112The hooks can be viewed as falling into two major
113categories: hooks that are used to manage the security fields and hooks
114that are used to perform access control. Examples of the first category
115of hooks include the security_inode_alloc() and security_inode_free()
116These hooks are used to allocate
117and free security structures for inode objects.
118An example of the second category of hooks
119is the security_inode_permission() hook.
120This hook checks permission when accessing an inode.
121
122LSM Capabilities Module
123=======================
124
125The POSIX.1e capabilities logic is maintained as a security module
126stored in the file ``security/commoncap.c``. The capabilities
127module uses the order field of the :c:type:`lsm_info` description
128to identify it as the first security module to be registered.
129The capabilities security module does not use the general security
130blobs, unlike other modules. The reasons are historical and are
131based on overhead, complexity and performance concerns.