<?xml version="1.0" encoding="ANSI_X3.4-1968" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=ANSI_X3.4-1968" /><title>LSM Framework</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /><link rel="home" href="index.html" title="Linux Security Modules: General Security Hooks for Linux" /><link rel="up" href="index.html" title="Linux Security Modules: General Security Hooks for Linux" /><link rel="prev" href="index.html" title="Linux Security Modules: General Security Hooks for Linux" /><link rel="next" href="ar01s03.html" title="LSM Capabilities Module" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">LSM Framework</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="index.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ar01s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" title="LSM Framework"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="framework"></a>LSM Framework</h2></div></div></div><p> The LSM kernel patch 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 auditing. By itself, the framework does not provide any additional security; it merely provides the infrastructure to support security modules. The LSM kernel patch also moves most of the capabilities logic into an optional security module, with the system defaulting to the traditional superuser logic. This capabilities module is discussed further in <a class="xref" href="ar01s03.html" title="LSM Capabilities Module">the section called “LSM Capabilities Module”</a>. </p><p> The LSM kernel patch adds security fields to kernel data structures and inserts 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 and unregistering security modules, and adds a general <code class="function">security</code> system call to support new system calls for security-aware applications. </p><p> The LSM security fields are simply <span class="type">void*</span> pointers. For process and program execution security information, security fields were added to <span class="structname">struct task_struct</span> and <span class="structname">struct linux_binprm</span>. For filesystem security information, a security field was added to <span class="structname">struct super_block</span>. For pipe, file, and socket security information, security fields were added to <span class="structname">struct inode</span> and <span class="structname">struct file</span>. For packet and network device security information, security fields were added to <span class="structname">struct sk_buff</span> and <span class="structname">struct net_device</span>. For System V IPC security information, security fields were added to <span class="structname">struct kern_ipc_perm</span> and <span class="structname">struct msg_msg</span>; additionally, the definitions for <span class="structname">struct msg_msg</span>, <span class="structname">struct msg_queue</span>, and <span class="structname">struct shmid_kernel</span> were moved to header files (<code class="filename">include/linux/msg.h</code> and <code class="filename">include/linux/shm.h</code> as appropriate) to allow the security modules to use these definitions. </p><p> Each LSM hook is a function pointer in a global table, security_ops. This table is a <span class="structname">security_operations</span> structure as defined by <code class="filename">include/linux/security.h</code>. Detailed documentation for each hook is included in this header file. At present, this structure consists of a collection of substructures that group related hooks based on the kernel object (e.g. task, inode, file, sk_buff, etc) as well as some top-level hook function pointers for system operations. This structure is likely to be flattened in the future for performance. The placement of the hook calls in the kernel code is described by the "called:" lines in the per-hook documentation in the header file. The hook calls can also be easily found in the kernel code by looking for the string "security_ops->". </p><p> Linus mentioned per-process security hooks in his original remarks as a possible alternative to global security hooks. However, if LSM were to start from the perspective of per-process hooks, then the base framework would have to deal with how to handle operations that involve multiple processes (e.g. kill), since each process might have its own hook for controlling the operation. This would require a general mechanism for composing hooks in the base framework. Additionally, LSM would still need global hooks for operations that have no process context (e.g. network input operations). Consequently, LSM provides global security hooks, but a security module is free to implement per-process hooks (where that makes sense) by storing a security_ops table in each process' security field and then invoking these per-process hooks from the global hooks. The problem of composition is thus deferred to the module. </p><p> The global security_ops table is initialized to a set of hook functions provided by a dummy security module that provides traditional superuser logic. A <code class="function">register_security</code> function (in <code class="filename">security/security.c</code>) is provided to allow a security module to set security_ops to refer to its own hook functions, and an <code class="function">unregister_security</code> function is provided to revert security_ops to the dummy module hooks. This mechanism is used to set the primary security module, which is responsible for making the final decision for each hook. </p><p> LSM also provides a simple mechanism for stacking additional security modules with the primary security module. It defines <code class="function">register_security</code> and <code class="function">unregister_security</code> hooks in the <span class="structname">security_operations</span> structure and provides <code class="function">mod_reg_security</code> and <code class="function">mod_unreg_security</code> functions that invoke these hooks after performing some sanity checking. A security module can call these functions in order to stack with other modules. However, the actual details of how this stacking is handled are deferred to the module, which can implement these hooks in any way it wishes (including always returning an error if it does not wish to support stacking). In this manner, LSM again defers the problem of composition to the module. </p><p> Although the LSM hooks are organized into substructures based on kernel object, all of 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 <code class="function">alloc_security</code> and <code class="function">free_security</code> hooks defined for each kernel data structure that has a security field. These hooks are used to allocate and free security structures for kernel objects. The first category of hooks also includes hooks that set information in the security field after allocation, such as the <code class="function">post_lookup</code> hook in <span class="structname">struct inode_security_ops</span>. This hook is used to set security information for inodes after successful lookup operations. An example of the second category of hooks is the <code class="function">permission</code> hook in <span class="structname">struct inode_security_ops</span>. This hook checks permission when accessing an inode. </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="index.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ar01s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Linux Security Modules: General Security Hooks for Linux </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> LSM Capabilities Module</td></tr></table></div></body></html>
