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
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
|
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-referencepolicy.xml,v 1.3 2011/06/07 19:46:52 klondike Exp $ -->
<sections>
<version>1</version>
<date>2011-06-02</date>
<section>
<title>About SELinux Policies</title>
<subsection>
<title>SELinux Policy Language</title>
<body>
<p>
As described previously, SELinux uses type enforcement to describe the state of
your system. This is done by giving each resource on your system (be it a
process, a network port, a file or directory) a specific type and describe the
rules how types can work with each other.
</p>
<p>
For instance, the allow-rule to allow all regular users (which are in the
user_t domain) to execute files with the bin_t label:
</p>
<pre caption="Allow rule to execute bin_t files">
allow user_t bin_t:file { read execute open };
</pre>
<p>
Other supported rules are
</p>
<ul>
<li>
<e>dontaudit</e> will disable the logging of the denial message(s)
</li>
<li>
<e>auditallow</e> will allow the access but will also log it (by default,
allowances are not logged)
</li>
<li>
<e>neverallow</e> forces that a certain allow rule cannot be granted. Even
though SELinux is a positive security model (white listing), sometimes
neverallow rules might be needed. But generally you will not often see them.
</li>
</ul>
<p>
As you can imagine, defining the rules for an entire system is very
resource-intensive if you want to do it right. It not only requires a deep
insight in how the system works, but also a lot of rule writing and testing. But
even more time consuming is that you will write the same rules over and over
again for different domains. To help developers with policy writing, a
<e>reference policy</e> has been brought to life with the following required
functionalities:
</p>
<ul>
<li>
development of SELinux policy rules should be centralized even for different
distributions
</li>
<li>
a macro language should be supported that makes it easier to write new
policies
</li>
<li>
the policies should be modular, allowing for additional rules to be added or
removed
</li>
</ul>
<p>
By centralizing the SELinux policy rule development, SELinux users will have the
same domain naming conventions as on other distributions. This makes debugging a
lot easier, documenting a lot less distribution-specific and makes it a bit
easier for end users to get acquainted with SELinux.
</p>
</body>
</subsection>
<subsection>
<title>Tresys Reference Policy</title>
<body>
<p>
The reference policy by choice is the <uri
link="http://oss.tresys.com/projects/refpolicy">Tresys SELinux Reference
Policy</uri>. This reference policy - currently at major version 2 - is used by
almost all SELinux supporting distributions, including Gentoo Hardened, Fedora,
RedHat Enterprise Linux, Debian, Ubuntu and more. This implementation not only
offers the modular policies that users are looking for, but also enhances the
SELinux experience with additional development tools that make it easier to
work with the SELinux policies on your system.
</p>
<p>
The reference policy starts off with a <e>base</e> policy called
<path>base.pp</path>. This is a collection of policies needed to get a system up
and running and also offers the necessary functions towards the policy modules.
In Gentoo Hardened, this base policy is offered by <c>selinux-base-policy</c>.
</p>
<p>
The policy modules themselves also use the <path>.pp</path> extension, but are
named more appropriately towards their content. For instance, the policy module
that contains all policy rules for the <c>screen</c> application is called
<path>screen.pp</path>. However, don't count on all policy modules to be named
after the tool: the policy module that contains the <c>wpa_supplicant</c>
specific rules is called <path>networkmanager.pp</path>. In Gentoo Hardened, the
modular policies are available in the <path>sec-policy</path> category and are
named <path>selinux-<module></path>.
</p>
<p>
To get a list of running modules, run <c>semodule</c>:
</p>
<pre caption="Listing the running SELinux policy modules">
~# <i>semodule -l</i>
dbus 1.14.0
dnsmasq 1.9.0
hal 1.13.0
[...]
</pre>
</body>
</subsection>
<subsection>
<title>Toggle Policy States</title>
<body>
<p>
As policies are built off from a "deny all" perspective, you can imagine that
there are thousands of rules already available in the reference policy.
Sometimes the developers know that particular rules will be active on one system
and inactive on another. Although this can be accomplished by developing two
different modules, SELinux development has opted to support <e>SELinux
booleans</e>.
</p>
<p>
SELinux booleans allow for rules to be conditionally applied, based on the
administrator's requirements. You can get a list of supported booleans through
<c>getsebool</c>:
</p>
<pre caption="Getting a list of supported booleans and their current state">
~# <i>getsebool -a</i>
allow_execheap --> off
allow_execmem --> off
[...]
fcron_crond --> off
global_ssp --> on
[...]
</pre>
<p>
If you need to change a boolean, you can use <c>togglesebool</c> to switch its
value, or <c>setsebool</c> so explicitly set its state:
</p>
<pre caption="Toggling boolean states">
~# <i>getsebool user_dmesg</i>
user_dmesg --> off
~# <i>togglesebool user_dmesg</i>
user_dmesg: active
<comment>(Now, the state is set to 'on')</comment>
~# <i>getsebool user_dmesg</i>
user_dmesg --> on
<comment>(Explicitly set the value to 'off')</comment>
~# <i>setsebool user_dmesg off</i>
</pre>
</body>
</subsection>
<subsection>
<title>Policy Files and Locations</title>
<body>
<p>
On Gentoo Hardened, the SELinux policy files are stored in
<path>/usr/share/selinux/strict</path> or
<path>/usr/share/selinux/targeted</path> (depending on your SELinux
configuration). Within this location, you will find:
</p>
<ul>
<li>
a file called <path>base.pp</path>, which is the SELinux base policy,
</li>
<li>
one or more files with extension <path>.pp</path>, which are the SELinux
policy modules, and
</li>
<li>
an <path>include/</path> folder which contains the necessary files for
SELinux module developers to build additional modules for this system
</li>
</ul>
</body>
</subsection>
<subsection>
<title>Policy Versions</title>
<body>
<p>
The SELinux policy infrastructure that is used (i.e. the capabilities and
functionalities that it offers) isn't in its first version. If you would run
<c>sestatus</c> now, you'll notice that we are using policy version 24. Every
time functionalities or capabilities are added which require changes to the
internal structure of the compiled policy, this version is incremented. The
following is an overview of the policy versions' history.
</p>
<dl>
<dt>Version 12</dt>
<dd>"Old API" for SELinux, which is now deprecated</dd>
<dt>Version 15</dt>
<dd>"New API" for SELinux, merged in Linux kernel 2.6.0 (until 2.6.5)</dd>
<dt>Version 16</dt>
<dd>Conditional policy extensions added (2.6.5)</dd>
<dt>Version 17</dt>
<dd>IPV6 support added (2.6.6 - 2.6.7)</dd>
<dt>Version 18</dt>
<dd>Fine-grained netlink socket support added (2.6.8 - 2.6.11)</dd>
<dt>Version 19</dt>
<dd>Enhanced multi-level security (2.6.12 - 2.6.13)</dd>
<dt>Version 20</dt>
<dd>Access vector table size optimizations (2.6.14 - 2.6.18)</dd>
<dt>Version 21</dt>
<dd>Object classes in range transitions (2.6.19 - 2.6.24)</dd>
<dt>Version 22</dt>
<dd>Policy capabilities (features) (2.6.25)</dd>
<dt>Version 23</dt>
<dd>Per-domain permissive mode (2.6.26 - 2.6.27)</dd>
<dt>Version 24</dt>
<dd>Explicit hierarchy (type bounds) (2.6.28 - 2.6.38)</dd>
<dt>Version 25</dt>
<dd>Filename based transition support (2.6.39)</dd>
<dt>Version 26</dt>
<dd>Role transition support for non-process classes (3.0)</dd>
</dl>
</body>
</subsection>
</section>
</sections>
|
GitWeb