1<html><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.78.1"><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="cap.html" title="LSM Capabilities Module"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><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="cap.html">Next</a></td></tr></table><hr></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="framework"></a>LSM Framework</h2></div></div></div><p> 2The LSM kernel patch provides a general kernel framework to support 3security modules. In particular, the LSM framework is primarily 4focused on supporting access control modules, although future 5development is likely to address other security needs such as 6auditing. By itself, the framework does not provide any additional 7security; it merely provides the infrastructure to support security 8modules. The LSM kernel patch also moves most of the capabilities 9logic into an optional security module, with the system defaulting 10to the traditional superuser logic. This capabilities module 11is discussed further in <a class="xref" href="cap.html" title="LSM Capabilities Module">the section called “LSM Capabilities Module”</a>. 12</p><p> 13The LSM kernel patch adds security fields to kernel data structures 14and inserts calls to hook functions at critical points in the kernel 15code to manage the security fields and to perform access control. It 16also adds functions for registering and unregistering security 17modules, and adds a general <code class="function">security</code> system call 18to support new system calls for security-aware applications. 19</p><p> 20The LSM security fields are simply <span class="type">void*</span> pointers. For 21process and program execution security information, security fields 22were added to <span class="structname">struct task_struct</span> and 23<span class="structname">struct linux_binprm</span>. For filesystem security 24information, a security field was added to 25<span class="structname">struct super_block</span>. For pipe, file, and socket 26security information, security fields were added to 27<span class="structname">struct inode</span> and 28<span class="structname">struct file</span>. For packet and network device security 29information, security fields were added to 30<span class="structname">struct sk_buff</span> and 31<span class="structname">struct net_device</span>. For System V IPC security 32information, security fields were added to 33<span class="structname">struct kern_ipc_perm</span> and 34<span class="structname">struct msg_msg</span>; additionally, the definitions 35for <span class="structname">struct msg_msg</span>, <span class="structname">struct 36msg_queue</span>, and <span class="structname">struct 37shmid_kernel</span> were moved to header files 38(<code class="filename">include/linux/msg.h</code> and 39<code class="filename">include/linux/shm.h</code> as appropriate) to allow 40the security modules to use these definitions. 41</p><p> 42Each LSM hook is a function pointer in a global table, 43security_ops. This table is a 44<span class="structname">security_operations</span> structure as defined by 45<code class="filename">include/linux/security.h</code>. Detailed documentation 46for each hook is included in this header file. At present, this 47structure consists of a collection of substructures that group related 48hooks based on the kernel object (e.g. task, inode, file, sk_buff, 49etc) as well as some top-level hook function pointers for system 50operations. This structure is likely to be flattened in the future 51for performance. The placement of the hook calls in the kernel code 52is described by the "called:" lines in the per-hook documentation in 53the header file. The hook calls can also be easily found in the 54kernel code by looking for the string "security_ops->". 55 56</p><p> 57Linus mentioned per-process security hooks in his original remarks as a 58possible alternative to global security hooks. However, if LSM were 59to start from the perspective of per-process hooks, then the base 60framework would have to deal with how to handle operations that 61involve multiple processes (e.g. kill), since each process might have 62its own hook for controlling the operation. This would require a 63general mechanism for composing hooks in the base framework. 64Additionally, LSM would still need global hooks for operations that 65have no process context (e.g. network input operations). 66Consequently, LSM provides global security hooks, but a security 67module is free to implement per-process hooks (where that makes sense) 68by storing a security_ops table in each process' security field and 69then invoking these per-process hooks from the global hooks. 70The problem of composition is thus deferred to the module. 71</p><p> 72The global security_ops table is initialized to a set of hook 73functions provided by a dummy security module that provides 74traditional superuser logic. A <code class="function">register_security</code> 75function (in <code class="filename">security/security.c</code>) is provided to 76allow a security module to set security_ops to refer to its own hook 77functions, and an <code class="function">unregister_security</code> function is 78provided to revert security_ops to the dummy module hooks. This 79mechanism is used to set the primary security module, which is 80responsible for making the final decision for each hook. 81</p><p> 82LSM also provides a simple mechanism for stacking additional security 83modules with the primary security module. It defines 84<code class="function">register_security</code> and 85<code class="function">unregister_security</code> hooks in the 86<span class="structname">security_operations</span> structure and provides 87<code class="function">mod_reg_security</code> and 88<code class="function">mod_unreg_security</code> functions that invoke these 89hooks after performing some sanity checking. A security module can 90call these functions in order to stack with other modules. However, 91the actual details of how this stacking is handled are deferred to the 92module, which can implement these hooks in any way it wishes 93(including always returning an error if it does not wish to support 94stacking). In this manner, LSM again defers the problem of 95composition to the module. 96</p><p> 97Although the LSM hooks are organized into substructures based on 98kernel object, all of the hooks can be viewed as falling into two 99major categories: hooks that are used to manage the security fields 100and hooks that are used to perform access control. Examples of the 101first category of hooks include the 102<code class="function">alloc_security</code> and 103<code class="function">free_security</code> hooks defined for each kernel data 104structure that has a security field. These hooks are used to allocate 105and free security structures for kernel objects. The first category 106of hooks also includes hooks that set information in the security 107field after allocation, such as the <code class="function">post_lookup</code> 108hook in <span class="structname">struct inode_security_ops</span>. This hook 109is used to set security information for inodes after successful lookup 110operations. An example of the second category of hooks is the 111<code class="function">permission</code> hook in 112<span class="structname">struct inode_security_ops</span>. This hook checks 113permission when accessing an inode. 114</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="cap.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> 115