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