mirror of https://github.com/Qortal/Brooklyn
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
131 lines
6.1 KiB
131 lines
6.1 KiB
======================================================== |
|
Linux Security Modules: General Security Hooks for Linux |
|
======================================================== |
|
|
|
:Author: Stephen Smalley |
|
:Author: Timothy Fraser |
|
:Author: Chris Vance |
|
|
|
.. note:: |
|
|
|
The APIs described in this book are outdated. |
|
|
|
Introduction |
|
============ |
|
|
|
In March 2001, the National Security Agency (NSA) gave a presentation |
|
about Security-Enhanced Linux (SELinux) at the 2.5 Linux Kernel Summit. |
|
SELinux is an implementation of flexible and fine-grained |
|
nondiscretionary access controls in the Linux kernel, originally |
|
implemented as its own particular kernel patch. Several other security |
|
projects (e.g. RSBAC, Medusa) have also developed flexible access |
|
control architectures for the Linux kernel, and various projects have |
|
developed particular access control models for Linux (e.g. LIDS, DTE, |
|
SubDomain). Each project has developed and maintained its own kernel |
|
patch to support its security needs. |
|
|
|
In response to the NSA presentation, Linus Torvalds made a set of |
|
remarks that described a security framework he would be willing to |
|
consider for inclusion in the mainstream Linux kernel. He described a |
|
general framework that would provide a set of security hooks to control |
|
operations on kernel objects and a set of opaque security fields in |
|
kernel data structures for maintaining security attributes. This |
|
framework could then be used by loadable kernel modules to implement any |
|
desired model of security. Linus also suggested the possibility of |
|
migrating the Linux capabilities code into such a module. |
|
|
|
The Linux Security Modules (LSM) project was started by WireX to develop |
|
such a framework. LSM was a joint development effort by several security |
|
projects, including Immunix, SELinux, SGI and Janus, and several |
|
individuals, including Greg Kroah-Hartman and James Morris, to develop a |
|
Linux kernel patch that implements this framework. The work was |
|
incorporated in the mainstream in December of 2003. This technical |
|
report provides an overview of the framework and the capabilities |
|
security module. |
|
|
|
LSM Framework |
|
============= |
|
|
|
The LSM framework provides a general kernel framework to support |
|
security modules. In particular, the LSM framework is primarily focused |
|
on supporting access control modules, although future development is |
|
likely to address other security needs such as sandboxing. By itself, the |
|
framework does not provide any additional security; it merely provides |
|
the infrastructure to support security modules. The LSM framework is |
|
optional, requiring `CONFIG_SECURITY` to be enabled. The capabilities |
|
logic is implemented as a security module. |
|
This capabilities module is discussed further in |
|
`LSM Capabilities Module`_. |
|
|
|
The LSM framework includes security fields in kernel data structures and |
|
calls to hook functions at critical points in the kernel code to |
|
manage the security fields and to perform access control. |
|
It also adds functions for registering security modules. |
|
An interface `/sys/kernel/security/lsm` reports a comma separated list |
|
of security modules that are active on the system. |
|
|
|
The LSM security fields are simply ``void*`` pointers. |
|
The data is referred to as a blob, which may be managed by |
|
the framework or by the individual security modules that use it. |
|
Security blobs that are used by more than one security module are |
|
typically managed by the framework. |
|
For process and |
|
program execution security information, security fields are included in |
|
:c:type:`struct task_struct <task_struct>` and |
|
:c:type:`struct cred <cred>`. |
|
For filesystem |
|
security information, a security field is included in :c:type:`struct |
|
super_block <super_block>`. For pipe, file, and socket security |
|
information, security fields are included in :c:type:`struct inode |
|
<inode>` and :c:type:`struct file <file>`. |
|
For System V IPC security information, |
|
security fields were added to :c:type:`struct kern_ipc_perm |
|
<kern_ipc_perm>` and :c:type:`struct msg_msg |
|
<msg_msg>`; additionally, the definitions for :c:type:`struct |
|
msg_msg <msg_msg>`, struct msg_queue, and struct shmid_kernel |
|
were moved to header files (``include/linux/msg.h`` and |
|
``include/linux/shm.h`` as appropriate) to allow the security modules to |
|
use these definitions. |
|
|
|
For packet and |
|
network device security information, security fields were added to |
|
:c:type:`struct sk_buff <sk_buff>` and |
|
:c:type:`struct scm_cookie <scm_cookie>`. |
|
Unlike the other security module data, the data used here is a |
|
32-bit integer. The security modules are required to map or otherwise |
|
associate these values with real security attributes. |
|
|
|
LSM hooks are maintained in lists. A list is maintained for each |
|
hook, and the hooks are called in the order specified by CONFIG_LSM. |
|
Detailed documentation for each hook is |
|
included in the `include/linux/lsm_hooks.h` header file. |
|
|
|
The LSM framework provides for a close approximation of |
|
general security module stacking. It defines |
|
security_add_hooks() to which each security module passes a |
|
:c:type:`struct security_hooks_list <security_hooks_list>`, |
|
which are added to the lists. |
|
The LSM framework does not provide a mechanism for removing hooks that |
|
have been registered. The SELinux security module has implemented |
|
a way to remove itself, however the feature has been deprecated. |
|
|
|
The hooks can be viewed as falling into two major |
|
categories: hooks that are used to manage the security fields and hooks |
|
that are used to perform access control. Examples of the first category |
|
of hooks include the security_inode_alloc() and security_inode_free() |
|
These hooks are used to allocate |
|
and free security structures for inode objects. |
|
An example of the second category of hooks |
|
is the security_inode_permission() hook. |
|
This hook checks permission when accessing an inode. |
|
|
|
LSM Capabilities Module |
|
======================= |
|
|
|
The POSIX.1e capabilities logic is maintained as a security module |
|
stored in the file ``security/commoncap.c``. The capabilities |
|
module uses the order field of the :c:type:`lsm_info` description |
|
to identify it as the first security module to be registered. |
|
The capabilities security module does not use the general security |
|
blobs, unlike other modules. The reasons are historical and are |
|
based on overhead, complexity and performance concerns.
|
|
|