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
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
|
<?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-using-commands.xml,v 1.3 2011/06/07 19:46:52 klondike Exp $ -->
<sections>
<version>6</version>
<date>2011-10-15</date>
<section>
<title>SELinux Information Commands</title>
<subsection>
<title>Introduction</title>
<body>
<p>
You should currently have a SELinux enabled system (but running in permissive
mode, so it will not enforce its policy rules). So before we introduce you to
the world of SELinux and how you can add more rules to make sure your system
remains functional when you switch to enforcing mode, we first give a quick
overview of the various SELinux related commands.
</p>
<p>
We start off with state commands where you can get global information on SELinux
state (is it running in enforcing mode or not, versions etc.)
</p>
</body>
</subsection>
<subsection>
<title>Getting SELinux Status</title>
<body>
<p>
The first command we will talk about is <c>sestatus</c>.
</p>
<pre caption="Running sestatus">
# <i>sestatus</i>
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 24
Policy from config file: strict
</pre>
<p>
The output of this command shows you that SELinux is enabled and is currently in
the <e>permissive</e> mode. It also tells you that the system is configured to
run in <e>strict</e> mode - so no unconfined_t domain here.
</p>
<p>
The <c>sestatus</c> command also has an extended output if you run it with the
<c>-v</c> option. When this is done, the command returns the contexts of
important processes and files:
</p>
<pre caption="Running sestatus -v">
# <i>sestatus -v</i>
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: strict
Process contexts:
Current context: staff_u:sysadm_r:sysadm_t
Init context: system_u:system_r:init_t
/sbin/agetty system_u:system_r:getty_t
/usr/sbin/sshd system_u:system_r:sshd_t
File contexts:
Controlling term: staff_u:object_r:user_devpts_t
/sbin/init system_u:object_r:init_exec_t
/sbin/agetty system_u:object_r:getty_exec_t
/bin/login system_u:object_r:login_exec_t
/sbin/rc system_u:object_r:rc_exec_t
/usr/sbin/sshd system_u:object_r:sshd_exec_t
/sbin/unix_chkpwd system_u:object_r:chkpwd_exec_t
/etc/passwd system_u:object_r:etc_t
/etc/shadow system_u:object_r:shadow_t
/bin/sh system_u:object_r:bin_t -> system_u:object_r:shell_exec_t
/bin/bash system_u:object_r:shell_exec_t
/usr/bin/newrole system_u:object_r:newrole_exec_t
/lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:lib_t
/lib/ld-linux.so.2 system_u:object_r:lib_t -> system_u:object_r:ld_so_t
</pre>
<p>
Another general SELinux status command is <c>getenforce</c>, which allows you to
quickly see if your SELinux is running in enforcing mode (SELinux policies are
enforced), permissive (SELinux policies are checked and logged, but not
enforced) or disabled (SELinux policy is not loaded and thus not checked).
</p>
<pre caption="Using the getenforce command">
# <i>getenforce</i>
Enforcing
</pre>
</body>
</subsection>
<subsection>
<title>Getting SELinux Object Information</title>
<body>
<p>
Next on the table is the <c>seinfo</c> command. This command allows you to query
the running policy for all objects (types, roles, attributes, users, booleans
...) defined.
</p>
<p>
Common usages are:
</p>
<ul>
<li>
checking if a specific domain is defined on your system (in case you're
wondering if you need to load an additional SELinux policy module or not)
</li>
<li>
checking which domains a particular role can be in (in case you're wondering
if your regular users are allowed by SELinux policies to even be
transitioned towards a specific domain)
</li>
<li>
checking which attributes are assigned to a specific domain (or vice versa,
which domains have a specific attribute set) as some SELinux policy rules
work on attributes rather than domains
</li>
</ul>
<p>
As an example, we query if the crontab_t domain is known, if the user_r role can
use the contab_t domain and finally which domains have the cron_spool_type
attribute set.
</p>
<pre caption="Using seinfo">
# <i>seinfo -tcrontab_t</i>
crontab_t
# <i>seinfo -ruser_r -x</i>
user_r
Dominated Roles:
user_r
Types:
[...]
crontab_t
[...]
# <i>seinfo -acron_spool_type -x</i>
cron_spool_type
user_cron_spool_t
system_cron_spool_t
</pre>
</body>
</subsection>
<subsection>
<title>Querying SELinux Policy Rules</title>
<body>
<p>
A command which you will often use is <c>sesearch</c>. This command allows you
to query the current policy allow rules and is a huge help when trying to find
out if something is allowed (or why something isn't allowed).
</p>
<p>
The <c>sesearch</c> command is most often used with a source domain (<c>-s</c>),
target domain (<c>-t</c>) or both, the class for which you want to query allow
rules for (file, dir, socket, process ...) and the privilege you want to query
for (read, write, open, transition, execute ...).
</p>
<p>
For instance, to find out which domains can write the files that have the
shadow_t domain:
</p>
<pre caption="Querying allow rules with sesearch">
# <i>sesearch -t shadow_t -c file -p write -A</i>
Found 8 semantic av rules:
[...]
allow portage_t shadow_t : file { ioctl read write ... };
allow useradd_t shadow_t : file { ioctl read write ... };
...
</pre>
<p>
You will notice that there are sometimes results based on attributes rather than
domains:
</p>
<pre caption="Allow rule based on attribute">
allow portage_t file_type : file { ioctl read write ... };
</pre>
<p>
In this case, the source domain (portage_t) is allowed to write to files whose
domain have the file_type attribute set. If you get the feeling of these things,
you'll wonder if the above rule is not a flagrant security issue as almost all
domains for files have the file_type set. Yes and no - if we take a look at
which domains have file write privileges to file_type domains, you'll notice
that this is only portage:
</p>
<pre caption="Querying domains with file-write privileges to file_type domains">
# <i>sesearch -t file_type -c file -p write -A -d</i>
Found 1 semantic av rules:
allow portage_t file_type : file { ioctl read write ... };
</pre>
<p>
Note that we had one command without the <c>-d</c> option and one with. When
<c>-d</c> is given, the search will perform an exact search without resolving
the attributes. When <c>-d</c> is not given, it will resolve the attribute. In
the last command example, dropping <c>-d</c> would result in hundreds of allow
rules: for each domain that has file_type set, the search tries to find rules
that allow file-write access to that particular domain.
</p>
<p>
Another interesting functionality of the <c>sesearch</c> command is to show you
the rules that are applicable depending on the state of a boolean. If you want
to query on a particular boolean, use <c>-b</c>. If you want to see the logic
that the policy uses, use <c>-C</c> (and yes, both can be combined).
</p>
<p>
As an example, we'll check what we allow (or deny) when the <c>global_ssp</c>
boolean is set:
</p>
<pre caption="Checking the policy regarding the global_ssp boolean">
# <i>sesearch -b global_ssp -A -C -d</i>
Found 2 semantic av rules:
ET allow domain device_t : dir { getattr search open } ; [ global_ssp ]
ET allow domain urandom_device_t : chr_file { ioctl read getattr lock open } ; [ global_ssp ]
</pre>
<p>
The prefix you see shows two letters, relating to two important definitions:
</p>
<ul>
<li>
Is the rule currently <b>E</b>nabled or <b>D</b>isabled?
</li>
<li>
Does the boolean need to be set to <b>T</b>rue or <b>F</b>alse to enable the rule?
</li>
</ul>
</body>
</subsection>
<subsection>
<title>Getting Security Context Information</title>
<body>
<p>
During administrative tasks, and especially when you are checking if a SELinux
denial could be made, it is important to find out what the security context is
for a particular resource. Luckily, Gentoo Hardened - if properly installed -
has already patched some tools to allow you to get this information using your
standard tools.
</p>
<p>
To get the security context of a file, use <c>ls -Z</c>:
</p>
<pre caption="Getting a file security context">
~$ <i>ls -Z /etc/make.conf</i>
system_u:object_r:portage_conf_t /etc/make.conf
</pre>
<p>
To get the security context of a process, use <c>ps -Z</c>:
</p>
<pre caption="Getting a process security context">
# <i>ps -Z $(pidof init)</i>
LABEL PID TTY STAT TIME COMMAND
system_u:system_r:init_t 1 ? Ss 0:00 init [3]
</pre>
<p>
To get the security context of the current user, use <c>id -Z</c>:
</p>
<pre caption="Getting a user security context">
~$ <i>id -Z</i>
staff_u:staff_r:staff_t
</pre>
</body>
</subsection>
</section>
<section>
<title>Managing SELinux</title>
<subsection>
<title>Introduction</title>
<body>
<p>
Managing SELinux objects (booleans, users, ports, contexts ...) is most often
done using <c>semanage</c>. As this application offers the interface towards
various SELinux configurations, we dedicate an entire section on it, but will
also cover the commands that offer similar functionality (and are sometimes
easier to remember).
</p>
</body>
</subsection>
<subsection>
<title>Booleans</title>
<body>
<p>
We have already covered SELinux booleans earlier in this book as well as the
<c>getsebool</c> and <c>setsebool</c> commands. With <c>semanage</c> you can too
manage the booleans and, as an added bonus, listing the booleans will also show
the description of the boolean (even though there is still work to be done in
this area).
</p>
<pre caption="Listing the available SELinux booleans">
# <i>semanage boolean -l</i>
SELinux boolean Description
allow_ptrace -> off allow_ptrace
rsync_export_all_ro -> off rsync_export_all_ro
</pre>
<note>
As you will notice, most descriptions are just the boolean name, but you will
find more and more booleans with a better description as you get acquainted with
- and install more - SELinux policy modules.
</note>
<p>
You can set a boolean with both <c>setsebool</c> and <c>semanage</c>:
</p>
<pre caption="Setting SELinux boolean values">
# <i>semanage boolean -m --on -F user_dmesg</i>
</pre>
</body>
</subsection>
<subsection id="users">
<title>SELinux Users and Logins</title>
<body>
<p>
SELinux users and logins are different from Unix accounts. SELinux logins allow
you to map a Unix account to a SELinux user:
</p>
<pre caption="Listing the SELinux logins">
# <i>semanage login -l</i>
Login Name SELinux User
__default__ user_u
root root
swift staff_u
system_u system_u
</pre>
<p>
The default behavior is that users are logged on as the <e>user_u</e> SELinux
user. This SELinux user is a non-administrator user: it has no specific
privileges and should be used for every account that never requires elevated
privileges (so no <c>su</c> or <c>sudo</c> rights for anything).
</p>
<p>
The account you use to administer your system should be mapped to the
<c>staff_u</c> SELinux user (or its own user with the appropriate roles). This
can be accomplished as follows (example with the Unix account <e>anna</e>):
</p>
<pre caption="Letting 'anna' log on as 'staff_u'">
# <i>semanage login -a -s staff_u anna</i>
</pre>
<impo>
Make sure that whatever account you use to administer your system is mapped to
the <c>staff_u</c> user, or has the ability to switch to the <c>sysadm_r</c>
role. Portage only works from within the <c>sysadm_r</c> role.
</impo>
<p>
As mentioned, SELinux users are configured to be able to join in on one or more
roles. To list the available roles, you can use <c>semanage user -l</c>:
</p>
<pre caption="Listing login / role mappings">
# <i>semanage user -l</i>
SELinux User SELinux Roles
root staff_r sysadm_r
staff_u staff_r sysadm_r
[...]
</pre>
</body>
</subsection>
<subsection>
<title>Managing Ports</title>
<body>
<p>
Even network ports (like port 22 for SSH) are 'protected' by SELinux. To get an
overview of which domains are assigned to which ports (or port ranges) use
<c>semanage port -l</c>.
</p>
<pre caption="Listing SELinux managed ports">
# <i>semanage port -l | grep '22$'</i>
ssh_port_t tcp 22
</pre>
</body>
</subsection>
</section>
<section>
<title>Using SELinux</title>
<subsection>
<title>Introduction</title>
<body>
<p>
Up until now we've covered getting SELinux related information as well as
managing SELinux settings. However, users on a SELinux hardened system will also
need to know a few things about working with SELinux, including (but not limited
to) roles and role transitions.
</p>
</body>
</subsection>
<subsection>
<title>Switching Roles</title>
<body>
<p>
As a type enforcement access control system, SELinux allows particular roles to
be within a set of domains. If you are using a role which is not allowed within
a particular domain, you will not be successful in using that domain and will be
denied the actions assigned to that domain.
</p>
<p>
If your standard users are all SELinux user_u users (with the only supported
role being user_r) then those users will never need to switch roles (nor are
they allowed to). But users that are staff_u (or other users that have multiple
roles) those users should be made clear how they switch between roles. We have
already covered how to map such users to the correct SELinux user (see <uri
link="#users">SELinux Users and Logins</uri>).
</p>
<p>
The command that accomplishes switching roles is called <c>newrole</c>. It's
use is pretty straight forward.
</p>
<pre caption="Using newrole">
~$ <i>newrole -r sysadm_r</i>
Password: <comment>(Enter the users' password - not root's!)</comment>
</pre>
<p>
When performing a role transition, SELinux will ask the user to re-authenticate
through its users' password. If you are logged on as a regular user and used
<c>su</c> or <c>sudo</c> to become the root user, then <c>newrole</c> will still
require you to enter the regular users' password.
</p>
</body>
</subsection>
</section>
</sections>
|
GitWeb