This section describes the current support for stacking SELinux with other security modules. LSM provides only minimal support for stacking security modules, providing hooks for this purpose but deferring the details of how stacking is handled to the primary security module. Work is ongoing to enhance the stacking support of LSM as well as to provide a generic stacker module; see the linux-security-module mailing list for more information. At present, the SELinux security module only functions as a primary security module and provides minimal support for using either the dummy security module (traditional superuser logic) or the capabilities security module as a secondary security module. This allows SELinux to be combined with either the traditional superuser logic or with the Linux capabilities logic.
As mentioned in the Section called Initialization, the
selinux_init
function initializes the
secondary security module to the dummy security module, which is
always resident in the kernel, prior to registering the SELinux
security module. This allows the SELinux hook functions to
safely call the secondary hook functions. The
selinux_register_security
hook function sets the
secondary security module to a different module, such as the
capabilities module. The
selinux_unregister_security
hook function
restores the secondary security module to the dummy security module.
The dummy and capabilities security modules only implement a very
small subset of the hook functions. Hence, at present, the SELinux
security module only calls the secondary security module for this
small set of hooks, along with a few other hooks that were added upon
request for other security module writers. Since some of the dummy
and capability hook functions are implemented in terms of the
capable
function, stacking the
capable
hook is sufficient to cover several hooks
without needing to explicitly call the secondary module from the
individual hook. However, in most cases, there would be no harm other
than performance in always calling the secondary security module.
There are a few exceptions where calling the secondary module would
pose a problem for SELinux. The capability
inode_removexattr
and
inode_setxattr
functions require
CAP_SYS_ADMIN
for all attributes in the security
namespace, whereas SELinux applies its own finer-grained checking to
the security.selinux
attribute, so SELinux must
completely override the secondary module for these hooks. The
capability vm_enough_memory
function would
perform duplicate vm accounting if SELinux called it, so SELinux must
override it as well. The capability netlink_send
function sets the effective capability bitmap in the control buffer for
the netlink message from the current process' credentials, whereas SELinux
overrides this function with one that also applies SELinux permission checking.
The dummy and capabilities security modules are easy to stack with SELinux because they do not use the security fields LSM added to the kernel data structures. Stacking the SELinux module with any module that does use these fields will require the definition of a common security object header with a module identifier and a link for chaining multiple security objects on a single security field. Work is ongoing in this area on the linux-security-module mailing list.