lsm.rst 6.1 KB

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