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
222
223
224
225
226
|
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header$ -->
<guide link="/proj/en/hardened/selinux-policy.xml" lang="en">
<title>Gentoo Hardened SELinux Development Policy</title>
<author title="Author">
<mail link="sven.vermeulen@siphos.be">Sven Vermeulen</mail>
</author>
<abstract>
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.
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>4</version>
<date>2011-09-04</date>
<chapter>
<title>Principles</title>
<section>
<title>Rationale</title>
<body>
<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>
</body>
</section>
<section>
<title>Principles</title>
<body>
<p>
This policy is based upon the following set of principles. Note that principles
do <e>not</e> 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>
</body>
</section>
</chapter>
<chapter>
<title>SELinux Domains</title>
<section>
<title>No Role-Specific Domains</title>
<body>
<p>
The reference policy development method supports the use of role-specific
domains (like <e>staff_mozilla_t</e> versus <e>user_mozilla_t</e>). 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 <e>screen_t</e>
domain uses role-specific implementations (<e>staff_screen_t</e>) because the
domain needs to transition back to the caller (<e>staff_t</e> to
<e>staff_screen_t</e> which launches a shell or command in the <e>staff_t</e>
domain).
</p>
</body>
</section>
<section>
<title>Do Not Allow Cosmetic Denials</title>
<body>
<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 <e>optional dontaudit</e> statements until sufficient
testing (or inclusion upstream) warrants the messages to be hidden fully: the
<c>dontaudit</c> rule is managed by a boolean called
<c>gentoo_try_dontaudit</c>. If enabled, the AVC denials will be hidden using
the SELinux standard <c>dontaudit</c> 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
<c>dontaudit</c> 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>
</body>
</section>
</chapter>
<chapter>
<title>SELinux Roles</title>
<section>
<title>Only Reference Policy Suggested Roles</title>
<body>
<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>
</body>
</section>
</chapter>
<chapter>
<title>SELinux Packages</title>
<section>
<title>Name SELinux Policy Packages After Their Module</title>
<body>
<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 <path>sec-policy/selinux-<modname></path> 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>
</body>
</section>
</chapter>
</guide>
|
GitWeb