About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / DocBook / lsm.tmpl

Custom Search

Based on kernel version 4.10.8. Page generated on 2017-04-01 14:43 EST.

1	<?xml version="1.0" encoding="UTF-8"?>
2	<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
3		"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
5	<article class="whitepaper" id="LinuxSecurityModule" lang="en">
6	 <articleinfo>
7	 <title>Linux Security Modules:  General Security Hooks for Linux</title>
8	 <authorgroup>
9	 <author>
10	 <firstname>Stephen</firstname> 
11	 <surname>Smalley</surname>
12	 <affiliation>
13	 <orgname>NAI Labs</orgname>
14	 <address><email>ssmalley@nai.com</email></address>
15	 </affiliation>
16	 </author>
17	 <author>
18	 <firstname>Timothy</firstname> 
19	 <surname>Fraser</surname>
20	 <affiliation>
21	 <orgname>NAI Labs</orgname>
22	 <address><email>tfraser@nai.com</email></address>
23	 </affiliation>
24	 </author>
25	 <author>
26	 <firstname>Chris</firstname> 
27	 <surname>Vance</surname>
28	 <affiliation>
29	 <orgname>NAI Labs</orgname>
30	 <address><email>cvance@nai.com</email></address>
31	 </affiliation>
32	 </author>
33	 </authorgroup>
34	 </articleinfo>
36	<sect1 id="Introduction"><title>Introduction</title>
38	<para>
39	In March 2001, the National Security Agency (NSA) gave a presentation
40	about Security-Enhanced Linux (SELinux) at the 2.5 Linux Kernel
41	Summit.  SELinux is an implementation of flexible and fine-grained
42	nondiscretionary access controls in the Linux kernel, originally
43	implemented as its own particular kernel patch.  Several other
44	security projects (e.g. RSBAC, Medusa) have also developed flexible
45	access control architectures for the Linux kernel, and various
46	projects have developed particular access control models for Linux
47	(e.g. LIDS, DTE, SubDomain).  Each project has developed and
48	maintained its own kernel patch to support its security needs.
49	</para>
51	<para>
52	In response to the NSA presentation, Linus Torvalds made a set of
53	remarks that described a security framework he would be willing to
54	consider for inclusion in the mainstream Linux kernel.  He described a
55	general framework that would provide a set of security hooks to
56	control operations on kernel objects and a set of opaque security
57	fields in kernel data structures for maintaining security attributes.
58	This framework could then be used by loadable kernel modules to
59	implement any desired model of security.  Linus also suggested the
60	possibility of migrating the Linux capabilities code into such a
61	module.
62	</para>
64	<para>
65	The Linux Security Modules (LSM) project was started by WireX to
66	develop such a framework.  LSM is a joint development effort by
67	several security projects, including Immunix, SELinux, SGI and Janus,
68	and several individuals, including Greg Kroah-Hartman and James
69	Morris, to develop a Linux kernel patch that implements this
70	framework.  The patch is currently tracking the 2.4 series and is
71	targeted for integration into the 2.5 development series.  This
72	technical report provides an overview of the framework and the example
73	capabilities security module provided by the LSM kernel patch.
74	</para>
76	</sect1>
78	<sect1 id="framework"><title>LSM Framework</title>
80	<para>
81	The LSM kernel patch provides a general kernel framework to support
82	security modules.  In particular, the LSM framework is primarily
83	focused on supporting access control modules, although future
84	development is likely to address other security needs such as
85	auditing.  By itself, the framework does not provide any additional
86	security; it merely provides the infrastructure to support security
87	modules.  The LSM kernel patch also moves most of the capabilities
88	logic into an optional security module, with the system defaulting
89	to the traditional superuser logic.  This capabilities module
90	is discussed further in <xref linkend="cap"/>.
91	</para>
93	<para>
94	The LSM kernel patch adds security fields to kernel data structures
95	and inserts calls to hook functions at critical points in the kernel
96	code to manage the security fields and to perform access control.  It
97	also adds functions for registering and unregistering security
98	modules, and adds a general <function>security</function> system call
99	to support new system calls for security-aware applications.
100	</para>
102	<para>
103	The LSM security fields are simply <type>void*</type> pointers.  For
104	process and program execution security information, security fields
105	were added to <structname>struct task_struct</structname> and 
106	<structname>struct linux_binprm</structname>.  For filesystem security
107	information, a security field was added to 
108	<structname>struct super_block</structname>.  For pipe, file, and socket
109	security information, security fields were added to 
110	<structname>struct inode</structname> and 
111	<structname>struct file</structname>.  For packet and network device security
112	information, security fields were added to
113	<structname>struct sk_buff</structname> and
114	<structname>struct net_device</structname>.  For System V IPC security
115	information, security fields were added to
116	<structname>struct kern_ipc_perm</structname> and
117	<structname>struct msg_msg</structname>; additionally, the definitions
118	for <structname>struct msg_msg</structname>, <structname>struct 
119	msg_queue</structname>, and <structname>struct 
120	shmid_kernel</structname> were moved to header files
121	(<filename>include/linux/msg.h</filename> and
122	<filename>include/linux/shm.h</filename> as appropriate) to allow
123	the security modules to use these definitions.
124	</para>
126	<para>
127	Each LSM hook is a function pointer in a global table,
128	security_ops. This table is a
129	<structname>security_operations</structname> structure as defined by
130	<filename>include/linux/security.h</filename>.  Detailed documentation
131	for each hook is included in this header file.  At present, this
132	structure consists of a collection of substructures that group related
133	hooks based on the kernel object (e.g. task, inode, file, sk_buff,
134	etc) as well as some top-level hook function pointers for system
135	operations.  This structure is likely to be flattened in the future
136	for performance.  The placement of the hook calls in the kernel code
137	is described by the "called:" lines in the per-hook documentation in
138	the header file.  The hook calls can also be easily found in the
139	kernel code by looking for the string "security_ops->".
141	</para>
143	<para>
144	Linus mentioned per-process security hooks in his original remarks as a
145	possible alternative to global security hooks.  However, if LSM were
146	to start from the perspective of per-process hooks, then the base
147	framework would have to deal with how to handle operations that
148	involve multiple processes (e.g. kill), since each process might have
149	its own hook for controlling the operation.  This would require a
150	general mechanism for composing hooks in the base framework.
151	Additionally, LSM would still need global hooks for operations that
152	have no process context (e.g. network input operations).
153	Consequently, LSM provides global security hooks, but a security
154	module is free to implement per-process hooks (where that makes sense)
155	by storing a security_ops table in each process' security field and
156	then invoking these per-process hooks from the global hooks.
157	The problem of composition is thus deferred to the module.
158	</para>
160	<para>
161	The global security_ops table is initialized to a set of hook
162	functions provided by a dummy security module that provides
163	traditional superuser logic.  A <function>register_security</function>
164	function (in <filename>security/security.c</filename>) is provided to
165	allow a security module to set security_ops to refer to its own hook
166	functions, and an <function>unregister_security</function> function is
167	provided to revert security_ops to the dummy module hooks.  This
168	mechanism is used to set the primary security module, which is
169	responsible for making the final decision for each hook.
170	</para>
172	<para>
173	LSM also provides a simple mechanism for stacking additional security
174	modules with the primary security module.  It defines
175	<function>register_security</function> and
176	<function>unregister_security</function> hooks in the
177	<structname>security_operations</structname> structure and provides
178	<function>mod_reg_security</function> and
179	<function>mod_unreg_security</function> functions that invoke these
180	hooks after performing some sanity checking.  A security module can
181	call these functions in order to stack with other modules.  However,
182	the actual details of how this stacking is handled are deferred to the
183	module, which can implement these hooks in any way it wishes
184	(including always returning an error if it does not wish to support
185	stacking).  In this manner, LSM again defers the problem of
186	composition to the module.
187	</para>
189	<para>
190	Although the LSM hooks are organized into substructures based on
191	kernel object, all of the hooks can be viewed as falling into two
192	major categories: hooks that are used to manage the security fields
193	and hooks that are used to perform access control.  Examples of the
194	first category of hooks include the
195	<function>alloc_security</function> and
196	<function>free_security</function> hooks defined for each kernel data
197	structure that has a security field.  These hooks are used to allocate
198	and free security structures for kernel objects.  The first category
199	of hooks also includes hooks that set information in the security
200	field after allocation, such as the <function>post_lookup</function>
201	hook in <structname>struct inode_security_ops</structname>.  This hook
202	is used to set security information for inodes after successful lookup
203	operations.  An example of the second category of hooks is the
204	<function>permission</function> hook in 
205	<structname>struct inode_security_ops</structname>.  This hook checks
206	permission when accessing an inode.
207	</para>
209	</sect1>
211	<sect1 id="cap"><title>LSM Capabilities Module</title>
213	<para>
214	The LSM kernel patch moves most of the existing POSIX.1e capabilities
215	logic into an optional security module stored in the file
216	<filename>security/capability.c</filename>.  This change allows
217	users who do not want to use capabilities to omit this code entirely
218	from their kernel, instead using the dummy module for traditional
219	superuser logic or any other module that they desire.  This change
220	also allows the developers of the capabilities logic to maintain and
221	enhance their code more freely, without needing to integrate patches
222	back into the base kernel.
223	</para>
225	<para>
226	In addition to moving the capabilities logic, the LSM kernel patch
227	could move the capability-related fields from the kernel data
228	structures into the new security fields managed by the security
229	modules.  However, at present, the LSM kernel patch leaves the
230	capability fields in the kernel data structures.  In his original
231	remarks, Linus suggested that this might be preferable so that other
232	security modules can be easily stacked with the capabilities module
233	without needing to chain multiple security structures on the security field.
234	It also avoids imposing extra overhead on the capabilities module
235	to manage the security fields.  However, the LSM framework could
236	certainly support such a move if it is determined to be desirable,
237	with only a few additional changes described below.
238	</para>
240	<para>
241	At present, the capabilities logic for computing process capabilities
242	on <function>execve</function> and <function>set*uid</function>,
243	checking capabilities for a particular process, saving and checking
244	capabilities for netlink messages, and handling the
245	<function>capget</function> and <function>capset</function> system
246	calls have been moved into the capabilities module.  There are still a
247	few locations in the base kernel where capability-related fields are
248	directly examined or modified, but the current version of the LSM
249	patch does allow a security module to completely replace the
250	assignment and testing of capabilities.  These few locations would
251	need to be changed if the capability-related fields were moved into
252	the security field.  The following is a list of known locations that
253	still perform such direct examination or modification of
254	capability-related fields:
255	<itemizedlist>
256	<listitem><para><filename>fs/open.c</filename>:<function>sys_access</function></para></listitem>
257	<listitem><para><filename>fs/lockd/host.c</filename>:<function>nlm_bind_host</function></para></listitem>
258	<listitem><para><filename>fs/nfsd/auth.c</filename>:<function>nfsd_setuser</function></para></listitem>
259	<listitem><para><filename>fs/proc/array.c</filename>:<function>task_cap</function></para></listitem>
260	</itemizedlist>
261	</para>
263	</sect1>
265	</article>
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.