1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link title="new" rel="stylesheet" href="http://www.gentoo.org/css/main.css" type="text/css">
<link REL="shortcut icon" HREF="http://www.gentoo.org/favicon.ico" TYPE="image/x-icon">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/www-gentoo-org.xml" title="Gentoo Website">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/forums-gentoo-org.xml" title="Gentoo Forums">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/bugs-gentoo-org.xml" title="Gentoo Bugzilla">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/packages-gentoo-org.xml" title="Gentoo Packages">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/archives-gentoo-org.xml" title="Gentoo List Archives">
<title>Gentoo Linux Documentation
--
Gentoo Hardened SELinux Development Policy</title>
</head>
<body style="margin:0px;" bgcolor="#ffffff"><table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr><td valign="top" height="125" bgcolor="#45347b"><a href="http://www.gentoo.org/"><img border="0" src="http://www.gentoo.org/images/gtop-www.jpg" alt="Gentoo Logo"></a></td></tr>
<tr><td valign="top" align="right" colspan="1" bgcolor="#ffffff"><table border="0" cellspacing="0" cellpadding="0" width="100%"><tr>
<td width="99%" class="content" valign="top" align="left">
<br><h1>Gentoo Hardened SELinux Development Policy</h1>
<form name="contents" action="http://www.gentoo.org">
<b>Content</b>:
<select name="url" size="1" OnChange="location.href=form.url.options[form.url.selectedIndex].value" style="font-family:sans-serif,Arial,Helvetica"><option value="#doc_chap1">1. Principles</option>
<option value="#doc_chap2">2. SELinux Domains</option>
<option value="#doc_chap3">3. SELinux Roles</option>
<option value="#doc_chap4">4. SELinux Packages</option></select>
</form>
<p class="chaphead"><a name="doc_chap1"></a><span class="chapnum">1.
</span>Principles</p>
<p class="secthead"><a name="doc_chap1_sect1">Rationale</a></p>
<p>
SELinux policy rules are used to confine applications, potentially restricting
their use on a system. The rules are made to be managed by a security
administrator, someone (or a group of people) who was the final say in how a
system should behave. Due to the flexibility of SELinux policy rules, various
different implementations exist. One can have SELinux rules allowing everything
an application does, or rules that allows everything an application needs to
function properly - or somewhere in between. You can confine parts of an
application, or confine a group of applications. You can allow all roles to
execute applications, or only a few.
</p>
<p>
In short, SELinux policy rules allow you to define the security access rules
just the way you want them to be - and that's perfect. That's exactly what makes
SELinux this interesting.
</p>
<p>
The problem however is that a distribution such as Gentoo Hardened offers a
set of rules for a large set of users. As such, it needs to take certain
decisions itself on how it defines the SELinux policy rules. And to help the
developers in writing the policy rules, the same set of principles and
guidelines should be followed to offer the end user an integrated, consistent
set of SELinux policy rules.
</p>
<p>
That set of principles and guidelines can be found in this document. Note that
this is still subject to change. For instance, if Gentoo Hardened gains
sufficient developer resources it might change some principles, resulting in a
change of policy.
</p>
<p class="secthead"><a name="doc_chap1_sect2">Principles</a></p>
<p>
This policy is based upon the following set of principles. Note that principles
do <span class="emphasis">not</span> mean that they are to be considered mandatory. They guide us in
our definition of the policy and in handling of future events.
</p>
<dl>
<dt>Work As-Is</dt>
<dd>
Confined applications should still function properly. Gentoo Hardened users
who find that the policy is preventing the application to function the way
it is meant to work by its developers should be able to consider this as a
bug in the rules
</dd>
<dt>Hide the Complexity</dt>
<dd>
The complexity of the SELinux policy rules offered by Gentoo Hardened should
be hidden from a regular user/administrator. This includes hiding denials
that are considered to be harmless / cosmetic.
</dd>
<dt>Keep It Simple</dt>
<dd>
Simplicity is better. A set of rules, domains, types or roles that is easy
to describe is easier to manage.
</dd>
<dt>Be Reluctant to Trust</dt>
<dd>
Applications or resources that can be influenced by untrusted actors should
be individually protected. As such, they should not run in a common domain.
</dd>
<dt>Least Privilege</dt>
<dd>
Access privileges should be given on a need-to-have basis. No more, no less.
</dd>
<dt>Track Upstream</dt>
<dd>
When relying on external rules (such as offered from the reference policy)
we strive to configure those rules to fit our needs or, if enhancements are
needed, ensure that they do not interfere with the upstream rules - now or
in the future
</dd>
</dl>
<p class="chaphead"><a name="doc_chap2"></a><span class="chapnum">2.
</span>SELinux Domains</p>
<p class="secthead"><a name="doc_chap2_sect1">No Role-Specific Domains</a></p>
<p>
The reference policy development method supports the use of role-specific
domains (like <span class="emphasis">staff_mozilla_t</span> versus <span class="emphasis">user_mozilla_t</span>). These
domains are generated automatically the moment you assign the necessary
template(s) to the roles.
</p>
<p>
Although this offers a great deal of flexibility (you can have different access
controls for different roles) and a more strict segregation of access controls
(no single SELinux rule that potentially allows one role to influence the
resources in the domain of another role, even if the real user is the same), it
is more difficult to manage. Also, its flexibility already implies that the
security administrator of the system customizes Gentoo Hardened's policy.
</p>
<p>
For this reason, Gentoo Hardened will not create role-specific domains by
default. Exceptions are always possible. For instance, the <span class="emphasis">screen_t</span>
domain uses role-specific implementations (<span class="emphasis">staff_screen_t</span>) because the
domain needs to transition back to the caller (<span class="emphasis">staff_t</span> to
<span class="emphasis">staff_screen_t</span> which launches a shell or command in the <span class="emphasis">staff_t</span>
domain).
</p>
<p class="secthead"><a name="doc_chap2_sect2">Do Not Allow Cosmetic Denials</a></p>
<p>
When developing SELinux rules, the Gentoo Hardened SELinux developers will
implement the access permissions needed for an application to function properly
on their system. Additional rules are then added based on testing, feedback and
thorough analysis. A SELinux developer will never implement an access permission
without being confident that it is needed to allow the application to function
properly.
</p>
<p>
Instead, if a denial is given but seems to be cosmetic, the Gentoo Hardened
SELinux developer will use <span class="emphasis">optional dontaudit</span> statements until sufficient
testing (or inclusion upstream) warrants the messages to be hidden fully: the
<span class="code" dir="ltr">dontaudit</span> rule is managed by a boolean called
<span class="code" dir="ltr">gentoo_try_dontaudit</span>. If enabled, the AVC denials will be hidden using
the SELinux standard <span class="code" dir="ltr">dontaudit</span> statements.
</p>
<p>
This ensures that, if a user feels that the access enforcement is wrongly
denying particular access but is not showing it, he does not need to disable all
<span class="code" dir="ltr">dontaudit</span> statements immediately to verify: he can first switch off the
Gentoo Hardened-specific statements, which should limit the amount of denials he
suddenly gets in his audit logs and only shows those managed by Gentoo Hardened.
</p>
<p class="chaphead"><a name="doc_chap3"></a><span class="chapnum">3.
</span>SELinux Roles</p>
<p class="secthead"><a name="doc_chap3_sect1">Only Reference Policy Suggested Roles</a></p>
<p>
Gentoo Hardened will not create and maintain additional roles. We will limit the
supported roles to those offered and actively maintained by the reference policy.
</p>
<p>
Even though it is very simple to create roles for specific functions on your
SELinux systems, it is hard for a generic policy to create new roles that fit
the needs of most. We assume that, if there are such roles, then they are
managed and maintained by the reference policy.
</p>
<p class="chaphead"><a name="doc_chap4"></a><span class="chapnum">4.
</span>SELinux Packages</p>
<p class="secthead"><a name="doc_chap4_sect1">Name SELinux Policy Packages After Their Module</a></p>
<p>
SELinux policy packages should be called after the module they implement (and
not the Gentoo package for which the policy would be implemented). The name
should use the <span class="path" dir="ltr">sec-policy/selinux-<modname></span> syntax.
</p>
<p>
By using the upstream module name, we ensure that no collisions occur
(neither package name collisions as well as file collisions during
installations) and follow upstream strictly. It also keeps the naming
of the packages clean.
</p>
<br><p class="copyright">
The contents of this document, unless otherwise expressly stated, are licensed under the <a href="http://creativecommons.org/licenses/by-sa/2.5">CC-BY-SA-2.5</a> license. The <a href="http://www.gentoo.org/main/en/name-logo.xml"> Gentoo Name and Logo Usage Guidelines </a> apply.
</p>
<!--
<rdf:RDF xmlns="http://web.resource.org/cc/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<License rdf:about="http://creativecommons.org/licenses/by-sa/2.5/">
<permits rdf:resource="http://web.resource.org/cc/Reproduction" />
<permits rdf:resource="http://web.resource.org/cc/Distribution" />
<requires rdf:resource="http://web.resource.org/cc/Notice" />
<requires rdf:resource="http://web.resource.org/cc/Attribution" />
<permits rdf:resource="http://web.resource.org/cc/DerivativeWorks" />
<requires rdf:resource="http://web.resource.org/cc/ShareAlike" />
</License>
</rdf:RDF>
--><br>
</td>
<td width="1%" bgcolor="#dddaec" valign="top"><table border="0" cellspacing="4px" cellpadding="4px">
<tr><td class="topsep" align="center"><p class="altmenu"><a title="View a printer-friendly version" class="altlink" href="selinux-policy.xml?style=printable">Print</a></p></td></tr>
<tr><td class="topsep" align="center"><p class="alttext">Updated September 4, 2011</p></td></tr>
<tr><td class="topsep" align="left"><p class="alttext"><b>Summary: </b>
Developing a set of security rules is or should always be done with a common set
of principles and rules in mind. This document explains the policy used by
Gentoo Hardened in order to consistenly develop its security policy rules.
</p></td></tr>
<tr><td align="left" class="topsep"><p class="alttext">
<a href="mailto:sven.vermeulen@siphos.be" class="altlink"><b>Sven Vermeulen</b></a>
<br><i>Author</i><br></p></td></tr>
<tr lang="en"><td align="center" class="topsep">
<p class="alttext"><b>Donate</b> to support our development efforts.
</p>
<form action="https://www.paypal.com/cgi-bin/webscr" method="post">
<input type="hidden" name="cmd" value="_xclick"><input type="hidden" name="business" value="paypal@gentoo.org"><input type="hidden" name="item_name" value="Gentoo Linux Support"><input type="hidden" name="item_number" value="1000"><input type="hidden" name="image_url" value="http://www.gentoo.org/images/paypal.png"><input type="hidden" name="no_shipping" value="1"><input type="hidden" name="return" value="http://www.gentoo.org"><input type="hidden" name="cancel_return" value="http://www.gentoo.org"><input type="image" src="http://images.paypal.com/images/x-click-but21.gif" name="submit" alt="Donate to Gentoo">
</form>
</td></tr>
<tr lang="en"><td align="center"><iframe src="http://sidebar.gentoo.org" scrolling="no" width="125" height="850" frameborder="0" style="border:0px padding:0x" marginwidth="0" marginheight="0"><p>Your browser does not support iframes.</p></iframe></td></tr>
</table></td>
</tr></table></td></tr>
<tr><td colspan="2" align="right" class="infohead">
Copyright 2001-2011 Gentoo Foundation, Inc. Questions, Comments? <a class="highlight" href="http://www.gentoo.org/main/en/contact.xml">Contact us</a>.
</td></tr>
</table></body>
</html>
|
GitWeb