132 lines · plain
1========================================================2Linux Security Modules: General Security Hooks for Linux3========================================================4 5:Author: Stephen Smalley6:Author: Timothy Fraser7:Author: Chris Vance8 9.. note::10 11 The APIs described in this book are outdated.12 13Introduction14============15 16In March 2001, the National Security Agency (NSA) gave a presentation17about Security-Enhanced Linux (SELinux) at the 2.5 Linux Kernel Summit.18SELinux is an implementation of flexible and fine-grained19nondiscretionary access controls in the Linux kernel, originally20implemented as its own particular kernel patch. Several other security21projects (e.g. RSBAC, Medusa) have also developed flexible access22control architectures for the Linux kernel, and various projects have23developed particular access control models for Linux (e.g. LIDS, DTE,24SubDomain). Each project has developed and maintained its own kernel25patch to support its security needs.26 27In response to the NSA presentation, Linus Torvalds made a set of28remarks that described a security framework he would be willing to29consider for inclusion in the mainstream Linux kernel. He described a30general framework that would provide a set of security hooks to control31operations on kernel objects and a set of opaque security fields in32kernel data structures for maintaining security attributes. This33framework could then be used by loadable kernel modules to implement any34desired model of security. Linus also suggested the possibility of35migrating the Linux capabilities code into such a module.36 37The Linux Security Modules (LSM) project was started by WireX to develop38such a framework. LSM was a joint development effort by several security39projects, including Immunix, SELinux, SGI and Janus, and several40individuals, including Greg Kroah-Hartman and James Morris, to develop a41Linux kernel patch that implements this framework. The work was42incorporated in the mainstream in December of 2003. This technical43report provides an overview of the framework and the capabilities44security module.45 46LSM Framework47=============48 49The LSM framework provides a general kernel framework to support50security modules. In particular, the LSM framework is primarily focused51on supporting access control modules, although future development is52likely to address other security needs such as sandboxing. By itself, the53framework does not provide any additional security; it merely provides54the infrastructure to support security modules. The LSM framework is55optional, requiring `CONFIG_SECURITY` to be enabled. The capabilities56logic is implemented as a security module.57This capabilities module is discussed further in58`LSM Capabilities Module`_.59 60The LSM framework includes security fields in kernel data structures and61calls to hook functions at critical points in the kernel code to62manage 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 list65of 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 by69the framework or by the individual security modules that use it.70Security blobs that are used by more than one security module are71typically managed by the framework.72For process and73program execution security information, security fields are included in74:c:type:`struct task_struct <task_struct>` and75:c:type:`struct cred <cred>`.76For filesystem77security information, a security field is included in :c:type:`struct78super_block <super_block>`. For pipe, file, and socket security79information, security fields are included in :c:type:`struct inode80<inode>` and :c:type:`struct file <file>`.81For System V IPC security information,82security fields were added to :c:type:`struct kern_ipc_perm83<kern_ipc_perm>` and :c:type:`struct msg_msg84<msg_msg>`; additionally, the definitions for :c:type:`struct85msg_msg <msg_msg>`, struct msg_queue, and struct shmid_kernel86were moved to header files (``include/linux/msg.h`` and87``include/linux/shm.h`` as appropriate) to allow the security modules to88use these definitions.89 90For packet and91network device security information, security fields were added to92:c:type:`struct sk_buff <sk_buff>` and93:c:type:`struct scm_cookie <scm_cookie>`.94Unlike the other security module data, the data used here is a9532-bit integer. The security modules are required to map or otherwise96associate these values with real security attributes.97 98LSM hooks are maintained in lists. A list is maintained for each99hook, and the hooks are called in the order specified by CONFIG_LSM.100Detailed documentation for each hook is101included in the `security/security.c` source file.102 103The LSM framework provides for a close approximation of104general security module stacking. It defines105security_add_hooks() to which each security module passes a106: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 that109have been registered. The SELinux security module has implemented110a way to remove itself, however the feature has been deprecated.111 112The hooks can be viewed as falling into two major113categories: hooks that are used to manage the security fields and hooks114that are used to perform access control. Examples of the first category115of hooks include the security_inode_alloc() and security_inode_free()116These hooks are used to allocate117and free security structures for inode objects.118An example of the second category of hooks119is the security_inode_permission() hook.120This hook checks permission when accessing an inode.121 122LSM Capabilities Module123=======================124 125The POSIX.1e capabilities logic is maintained as a security module126stored in the file ``security/commoncap.c``. The capabilities127module uses the order field of the :c:type:`lsm_info` description128to identify it as the first security module to be registered.129The capabilities security module does not use the general security130blobs, unlike other modules. The reasons are historical and are131based on overhead, complexity and performance concerns.132