Note

The APIs described in this book are outdated.

Introduction¶

In March 2001, the National Security Agency (NSA) gave a presentationabout Security-Enhanced Linux (SELinux) at the 2.5 Linux Kernel Summit.SELinux is an implementation of flexible and fine-grainednondiscretionary access controls in the Linux kernel, originallyimplemented as its own particular kernel patch. Several other securityprojects (e.g. RSBAC, Medusa) have also developed flexible accesscontrol architectures for the Linux kernel, and various projects havedeveloped particular access control models for Linux (e.g. LIDS, DTE,SubDomain). Each project has developed and maintained its own kernelpatch to support its security needs.

In response to the NSA presentation, Linus Torvalds made a set ofremarks that described a security framework he would be willing toconsider for inclusion in the mainstream Linux kernel. He described ageneral framework that would provide a set of security hooks to controloperations on kernel objects and a set of opaque security fields inkernel data structures for maintaining security attributes. Thisframework could then be used by loadable kernel modules to implement anydesired model of security. Linus also suggested the possibility ofmigrating the Linux capabilities code into such a module.

The Linux Security Modules (LSM) project was started by WireX to developsuch a framework. LSM was a joint development effort by several securityprojects, including Immunix, SELinux, SGI and Janus, and severalindividuals, including Greg Kroah-Hartman and James Morris, to develop aLinux kernel patch that implements this framework. The work wasincorporated in the mainstream in December of 2003. This technicalreport provides an overview of the framework and the capabilitiessecurity module.

LSM Framework¶

The LSM framework provides a general kernel framework to supportsecurity modules. In particular, the LSM framework is primarily focusedon supporting access control modules, although future development islikely to address other security needs such as sandboxing. By itself, theframework does not provide any additional security; it merely providesthe infrastructure to support security modules. The LSM framework isoptional, requiringCONFIG_SECURITY to be enabled. The capabilitieslogic is implemented as a security module.This capabilities module is discussed further inLSM Capabilities Module.

The LSM framework includes security fields in kernel data structures andcalls to hook functions at critical points in the kernel code tomanage 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 listof security modules that are active on the system.

The LSM security fields are simplyvoid* pointers.The data is referred to as a blob, which may be managed bythe framework or by the individual security modules that use it.Security blobs that are used by more than one security module aretypically managed by the framework.For process andprogram execution security information, security fields are included instructtask_struct andstructcred.For filesystemsecurity information, a security field is included instructsuper_block. For pipe, file, and socket securityinformation, security fields are included instructinode andstructfile.For System V IPC security information,security fields were added tostructkern_ipc_perm andstructmsg_msg; additionally, the definitions forstructmsg_msg, struct msg_queue, and struct shmid_kernelwere moved to header files (include/linux/msg.h andinclude/linux/shm.h as appropriate) to allow the security modules touse these definitions.

For packet andnetwork device security information, security fields were added tostructsk_buff andstructscm_cookie.Unlike the other security module data, the data used here is a32-bit integer. The security modules are required to map or otherwiseassociate these values with real security attributes.

LSM hooks are maintained in lists. A list is maintained for eachhook, and the hooks are called in the order specified by CONFIG_LSM.Detailed documentation for each hook isincluded in theinclude/linux/lsm_hooks.h header file.

The LSM framework provides for a close approximation ofgeneral security module stacking. It definessecurity_add_hooks() to which each security module passes astructsecurity_hooks_list,which are added to the lists.The LSM framework does not provide a mechanism for removing hooks thathave been registered. The SELinux security module has implementeda way to remove itself, however the feature has been deprecated.

The hooks can be viewed as falling into two majorcategories: hooks that are used to manage the security fields and hooksthat are used to perform access control. Examples of the first categoryof hooks include the security_inode_alloc() and security_inode_free()These hooks are used to allocateand free security structures for inode objects.An example of the second category of hooksis 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 modulestored in the filesecurity/commoncap.c. The capabilitiesmodule uses the order field of thelsm_info descriptionto identify it as the first security module to be registered.The capabilities security module does not use the general securityblobs, unlike other modules. The reasons are historical and arebased on overhead, complexity and performance concerns.