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
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
|
<!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 Frequently Asked Questions</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 Frequently Asked Questions</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. Questions</option>
<option value="#doc_chap2">2. General SELinux Support Questions</option>
<option value="#doc_chap3">3. Using SELinux</option>
<option value="#doc_chap4">4. SELinux Kernel Error Messages</option>
<option value="#doc_chap5">5. SELinux and Gentoo</option></select>
</form>
<p class="chaphead"><a name="doc_chap1"></a><span class="chapnum">1.
</span>Questions</p>
<p class="secthead"><a name="doc_chap1_sect1">Introduction</a></p>
<p>
Using SELinux requires administrators a more thorough knowledge of their
system and a good idea on how processes should behave. Next to the <a href="selinux/selinux-handbook.html">Gentoo Hardened SELinux
handbook</a>, a proper FAQ allows us to inform and help users in their
day-to-day SELinux experience.
</p>
<p>
The FAQ is an aggregation of solutions found on IRC, mailinglists, forums
and elsewhere. It focuses on SELinux integration on Gentoo Hardened, but
general SELinux questions that are popping up regularly will be incorporated
as well.
</p>
<p class="secthead">General SELinux Support Questions</p>
<ul>
<li><a href="#features">Does SELinux enforce resource limits?</a></li>
<li><a href="#grsecurity">Can I use SELinux with grsecurity (and PaX)?</a></li>
<li><a href="#pie-ssp">Can I use SELinux and the hardened compiler (with PIE-SSP)?</a></li>
<li><a href="#rsbac">Can I use SELinux and RSBAC?</a></li>
<li><a href="#filesystem">Can I use SELinux with any file system?</a></li>
<li><a href="#nomultilib">Can I use SELinux with AMD64 no-multilib?</a></li>
<li><a href="#ubac">What is UBAC exactly?</a></li>
</ul>
<p class="secthead">Using SELinux</p>
<ul>
<li><a href="#enable_selinux">How do I enable SELinux?</a></li>
<li><a href="#switch_status">How do I switch between permissive and enforcing?</a></li>
<li><a href="#disable_selinux">How do I disable SELinux completely?</a></li>
<li><a href="#matchcontext">How do I know which file context rule is used for a particular file?</a></li>
<li><a href="#localpolicy">How do I make small changes (additions) to the policy?</a></li>
</ul>
<p class="secthead">SELinux Kernel Error Messages</p>
<ul>
<li><a href="#register_security">I get a register_security error message when booting</a></li>
<li><a href="#permission_not_defined">I get a 'Permission ... in class ... not defined' message during booting</a></li>
</ul>
<p class="secthead">SELinux and Gentoo</p>
<ul>
<li><a href="#no_module">I get a missing SELinux module error when using emerge</a></li>
<li><a href="#loadpolicy">I get 'FEATURES variable contains unknown value(s): loadpolicy'</a></li>
<li><a href="#conflicting_types">During rlpkg I get 'conflicting specifications for ... and ..., using ...'</a></li>
<li><a href="#portage_libsandbox">During package installation, ld.so complains 'object 'libsandbox.so'
from LD_PRELOAD cannot be preloaded: ignored'</a></li>
<li><a href="#emergefails">Emerge does not work, giving 'Permission denied: /etc/make.conf'</a></li>
<li><a href="#cronfails">Cron fails to load in root's crontab with message '(root) ENTRYPOINT
FAILED (crontabs/root)'</a></li>
<li><a href="#missingdatum">When querying the policy, I get 'ERROR: could not find datum for type ...'</a></li>
<li><a href="#recoverportage">Portage fails to label files because "setfiles" does not work anymore</a></li>
<li><a href="#nosuid">Applications do not transition on a nosuid-mounted partition</a></li>
<li><a href="#auth-run_init">Why do I always need to re-authenticate when operating init scripts?</a></li>
<li><a href="#initramfs">How do I use SELinux with initramfs?</a></li>
</ul>
<p class="chaphead"><a name="doc_chap2"></a><span class="chapnum">2.
</span>General SELinux Support Questions</p>
<p class="secthead"><a name="features"></a><a name="doc_chap2_sect1">Does SELinux enforce resource limits?</a></p>
<p>
No, resource limits are outside the scope of an access control system. If you
are looking for this type of support, take a look at technologies like
grsecurity, cgroups, pam and the like.
</p>
<p class="secthead"><a name="grsecurity"></a><a name="doc_chap2_sect2">Can I use SELinux with grsecurity (and PaX)?</a></p>
<p>
Definitely, we even recommend it. However, it is suggested that grsecurity's
ACL support is not used as it would be redundant to SELinux's access control.
</p>
<p class="secthead"><a name="pie-ssp"></a><a name="doc_chap2_sect3">Can I use SELinux and the hardened compiler (with PIE-SSP)?</a></p>
<p>
Definitely. We also suggest to use PaX to take full advantage of the PIE
features of the compiler.
</p>
<p class="secthead"><a name="rsbac"></a><a name="doc_chap2_sect4">Can I use SELinux and RSBAC?</a></p>
<p>
Yes, SELinux and RSBAC can be used together, but it is not recommended.
Both frameworks (RSBAC and the SELinux implementation on top of Linux' Linux
Security Modules framework) have a slight impact on system performance.
Enabling them both only hinders performance more, for little added value since
they both offer similar functionality.
</p>
<p>
In most cases, it makes more sense to use RSBAC without SELinux, or SELinux
without RSBAC.
</p>
<p class="secthead"><a name="filesystem"></a><a name="doc_chap2_sect5">Can I use SELinux with any file system?</a></p>
<p>
SELinux requires access to a file's security context to operate properly.
To do so, SELinux uses <span class="emphasis">extended file attributes</span> which needs to be
properly supported by the underlying file system. If the file system supports
extended file attributes and you have configured your kernel to enable this
support, then SELinux will work on those file systems.
</p>
<p>
General Linux file systems, such as ext2, ext3, ext4, jfs, xfs and btrfs
support extended attributes (but don't forget to enable it in the kernel
configuration) as well as tmpfs (for instance used by udev). If your file
system collection is limited to this set, then you should have no issues.
</p>
<p>
Ancillary file systems such as vfat and iso9660 are supported too, but with
an important caveat: all files in each file system will have the same SELinux
security context information since these file systems do not support extended
file attributes.
</p>
<p>
Network file systems can be supported in the same manner as ancillary file
systems (all files share the same security context). However, some development
has been made in supported extended file attributes on the more popular file
systems such as NFS. Although this is far from production-ready, it does look
like we will eventually support these file systems on SELinux fully as well.
</p>
<p class="secthead"><a name="nomultilib"></a><a name="doc_chap2_sect6">Can I use SELinux with AMD64 no-multilib?</a></p>
<p>
Yes, just use the <span class="path" dir="ltr">hardened/linux/amd64/no-multilib/selinux</span> profile
and you're all set.
</p>
<p class="secthead"><a name="ubac"></a><a name="doc_chap2_sect7">What is UBAC exactly?</a></p>
<p>
UBAC, or <span class="emphasis">User Based Access Control</span>, introduces additional constraints
when using SELinux policy. Participating domains / types that are <span class="emphasis">both</span>
marked as a <span class="code" dir="ltr">ubac_constrained_type</span> (which is an attribute) will only
have the allowed privileges in effect if they both run with the same SELinux
user context.
</p>
<a name="doc_chap2_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing2.1: Domains and their SELinux user context</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
<span class="code-comment"># The SELinux allow rule</span>
allow foo_t bar_t:file { read };
<span class="code-comment"># This will succeed:</span>
staff_u:staff_r:foo_t reads file with type staff_u:object_r:bar_t
<span class="code-comment"># This will be prohibited:</span>
user_u:user_r:foo_t reads file with type staff_u:object_r:bar_t
</pre></td></tr>
</table>
<p>
Of course, this is not always the case. Besides the earlier mentioned
requirement that both types are <span class="code" dir="ltr">ubac_constrained_type</span>, if the source
domain is <span class="code" dir="ltr">sysadm_t</span>, then the constraint will not be in effect (the
<span class="code" dir="ltr">sysadm_t</span> domain is exempt from UBAC constraints). Also, if the source
or destination SELinux user is <span class="code" dir="ltr">system_u</span> then the constraint will also
not be in effect.
</p>
<p class="chaphead"><a name="doc_chap3"></a><span class="chapnum">3.
</span>Using SELinux</p>
<p class="secthead"><a name="enable_selinux"></a><a name="doc_chap3_sect1">How do I enable SELinux?</a></p>
<p>
This is explained in the <a href="selinux/selinux-handbook.html">SELinux Handbook</a>
in the chapter on <span class="emphasis">Using Gentoo/Hardened SELinux</span>.
</p>
<p class="secthead"><a name="switch_status"></a><a name="doc_chap3_sect2">How do I switch between permissive and enforcing?</a></p>
<p>
The easiest way is to use the <span class="code" dir="ltr">setenforce</span> command. With <span class="code" dir="ltr">setenforce
0</span> you tell SELinux to run in permissive mode. Similarly, with
<span class="code" dir="ltr">setenforce 1</span> you tell SELinux to run in enforcing mode.
</p>
<p>
You can also add a kernel option <span class="code" dir="ltr">enforcing=0</span> or <span class="code" dir="ltr">enforcing=1</span>
in the bootloader configuration (or during the startup routine of the system).
This allows you to run SELinux in permissive or enforcing mode from the start
of the system.
</p>
<p>
The default state of the system is kept in <span class="path" dir="ltr">/etc/selinux/config</span>.
</p>
<p class="secthead"><a name="disable_selinux"></a><a name="doc_chap3_sect3">How do I disable SELinux completely?</a></p>
<p>
It might be possible that running SELinux in permissive mode is not sufficient
to properly fix any issue you have. To disable SELinux completely, you need to
edit <span class="path" dir="ltr">/etc/selinux/config</span> and set <span class="code" dir="ltr">SELINUX=disabled</span>. Next,
reboot your system.
</p>
<table class="ncontent" width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td bgcolor="#ffffbb"><p class="note"><b>Important: </b>
When you have been running your system with SELinux disabled, you must boot
in permissive mode first and relabel your entire file system. Activities ran
while SELinux was disabled might have created new files or removed the labels
from existing files, causing these files to be available without security
context.
</p></td></tr></table>
<p class="secthead"><a name="matchcontext"></a><a name="doc_chap3_sect4">How do I know which file context rule is used for a particular file?</a></p>
<p>
If you use the <span class="code" dir="ltr">matchpathcon</span> command, it will tell you what the security
context for the given path (file or directory) should be, but it doesn't tell
you which rule it used to deduce this. To do that, you can use <span class="code" dir="ltr">findcon</span>:
</p>
<a name="doc_chap3_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.1: Using findcon</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
~# <span class="code-input">findcon /etc/selinux/strict/contexts/files/file_contexts -p /lib64/rc/init.d</span>
/.* system_u:object_r:default_t
/lib64/rc/init\.d(/.*)? system_u:object_r:initrc_state_t
/lib64/.* system_u:object_r:lib_t
</pre></td></tr>
</table>
<p>
When the SELinux utilities try to apply a context, they try to match the rule
that is the most specific, so in the above case, it is the one that leads to the
initrc_state_t context.
</p>
<p>
The most specific means, in order of tests:
</p>
<ol>
<li>
If line A has a regular expression, and line B doesn't, then line B is more
specific.
</li>
<li>
If the number of characters before the first regular expression in line A is
less than the number of characters before the first regular expression in
line B, then line B is more specific
</li>
<li>
If the number of characters in line A is less than in line B, then line B is
more specific
</li>
<li>
If line A does not map to a specific SELinux type, and line B does, then
line B is more specific
</li>
</ol>
<p>
However, when you add your own file contexts (using <span class="code" dir="ltr">semanage</span>), this does
not apply. Instead, tools like <span class="code" dir="ltr">restorecon</span> will take the <span class="emphasis">last</span> hit
within the locally added file contexts! You can check the content of the
locally added rules in <span class="path" dir="ltr">/etc/selinux/strict/contexts/files/file_contexts.local</span>
(substitute <span class="path" dir="ltr">strict</span> with your SELinux type).
</p>
<p class="secthead"><a name="localpolicy"></a><a name="doc_chap3_sect5">How do I make small changes (additions) to the policy?</a></p>
<p>
If you are interested in the Gentoo Hardened SELinux development itself, please
have a look at the <a href="selinux-development.html">SELinux
Development Guide</a> and other documentation linked from the <a href="selinux/index.html">SELinux project page</a>.
</p>
<p>
However, you will eventually need to keep some changes on your policy, due to
how you have configured your system or when you need to allow something that is
not going to be accepted as a distribution-wide policy change. In that case,
read on.
</p>
<p>
Updates on the policy are only possible as long as you need to <span class="emphasis">allow</span>
additional privileges. It is not possible to remove rules from the policy, only
enhance it. To maintain your own set of additional rules, create a file in which
you will keep your changes. In the next example, I will use the term
<span class="path" dir="ltr">fixlocal</span>, substitute with whatever name you like - but keep it
consistent. In the file (<span class="path" dir="ltr">fixlocal.te</span>) put in the following text
(again, substitute <span class="path" dir="ltr">fixlocal</span> with your chosen name):
</p>
<a name="doc_chap3_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.2: fixlocal.te content</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
policy_module(fixlocal, 1.0)
require {
<span class="code-comment"># Declarations of types, classes and permissions used</span>
}
<span class="code-comment"># Declaration of policy rules</span>
</pre></td></tr>
</table>
<p>
In this file, you can add rules as you like. In the next example, we add three
rules:
</p>
<ol>
<li>
Allow <span class="code" dir="ltr">mozilla_t</span> the <span class="code" dir="ltr">execmem</span> privilege (based on a denial that
occurs when mozilla fails to start)
</li>
<li>
Allow <span class="code" dir="ltr">ssh_t</span> to connect to any port rather than just the SSH port
</li>
<li>
Allows the <span class="code" dir="ltr">user_t</span> domain to send messages directly to the system
logger
</li>
</ol>
<a name="doc_chap3_pre3"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.3: fixlocal.te content</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
policy_module(fixlocal, 1.0)
require {
type mozilla_t;
type ssh_t;
type user_t;
class process { execmem };
}
<span class="code-comment"># Grant mozilla the execmem privilege</span>
allow mozilla_t self:process { execmem };
<span class="code-comment"># Allow SSH client to connect to any port (as provided by the user through the
# "ssh -p <portnum> ..." command)</span>
corenet_tcp_connect_all_ports(ssh_t)
<span class="code-comment"># Allow the user_t domain to send messages to the system logger</span>
logging_send_syslog_msg(user_t)
</pre></td></tr>
</table>
<p>
If you need to provide raw allow statements (like the one above for the
<span class="code" dir="ltr">mozilla_t</span> domain), make sure that the type (<span class="code" dir="ltr">mozilla_t</span>),
class (<span class="code" dir="ltr">process</span>) and privilege (<span class="code" dir="ltr">execmem</span>) are mentioned in
the <span class="code" dir="ltr">require { ... }</span> paragraph.
</p>
<p>
When using interface names, make sure that the types (<span class="code" dir="ltr">ssh_t</span> and
<span class="code" dir="ltr">user_t</span>) are mentioned in the <span class="code" dir="ltr">require { ... }</span> paragraph.
</p>
<p>
To find the proper interface name (like <span class="code" dir="ltr">corenet_tcp_connect_all_ports</span>
above), you can either look for it in the <a href="http://oss.tresys.com/docs/refpolicy/api/">SELinux Reference Policy
API</a> online or, if <span class="code" dir="ltr">sec-policy/selinux-base-policy</span> is built with the
<span class="emphasis">doc</span> USE flag, in <span class="path" dir="ltr">/usr/share/doc/selinux-base-policy-.*/html</span>.
Of course, you can also ask for help in <span class="code" dir="ltr">#gentoo-hardened</span> on
irc.freenode.net, the mailinglist, forums, etc. to find the proper rules and
statements for your case.
</p>
<p class="chaphead"><a name="doc_chap4"></a><span class="chapnum">4.
</span>SELinux Kernel Error Messages</p>
<p class="secthead"><a name="register_security"></a><a name="doc_chap4_sect1">I get a register_security error message when booting</a></p>
<p>
During boot-up, the following message pops up:
</p>
<a name="doc_chap4_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing4.1: Kernel message on register_security</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
There is already a security framework initialized, register_security failed.
Failure registering capabilities with the kernel
selinux_register_security: Registering secondary module capability
Capability LSM initialized
</pre></td></tr>
</table>
<p>
This is nothing to worry about (and perfectly normal).
</p>
<p>
This means that the Capability LSM module couldn't register as the primary
module, since SELinux is the primary module. The third message means that it
registers with SELinux as a secondary module.
</p>
<p class="secthead"><a name="permission_not_defined"></a><a name="doc_chap4_sect2">I get a 'Permission ... in class ... not defined' message during booting</a></p>
<p>
During boot-up, the following message is shown:
</p>
<a name="doc_chap4_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing4.2: Kernel message on undefined permission(s)</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
SELinux: 2048 avtab hash slots, 16926 rules.
SELinux: 2048 avtab hash slots, 16926 rules.
SELinux: 6 users, 6 roles, 1083 types, 34 bools
SELinux: 77 classes, 16926 rules
SELinux: Permission read_policy in class security not defined in policy.
SELinux: Permission audit_access in class file not defined in policy.
SELinux: Permission audit_access in class dir not defined in policy.
SELinux: Permission execmod in class dir not defined in policy.
...
SELinux: the above unknown classes and permissions will be denied
SELinux: Completing initialization.
</pre></td></tr>
</table>
<p>
This means that the Linux kernel that you are booting supports permissions that
are not defined in the policy (as offered through the
<span class="code" dir="ltr">sec-policy/selinux-base-policy</span> package). If you do not notice any errors
during regular operations, then this can be ignored (the permissions will be
made part of upcoming policy definitions).
</p>
<p class="chaphead"><a name="doc_chap5"></a><span class="chapnum">5.
</span>SELinux and Gentoo</p>
<p class="secthead"><a name="no_module"></a><a name="doc_chap5_sect1">I get a missing SELinux module error when using emerge</a></p>
<p>
When trying to use <span class="code" dir="ltr">emerge</span>, the following error message is displayed:
</p>
<a name="doc_chap5_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.1: Error message from emerge on the SELinux module</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
!!! SELinux module not found. Please verify that it was installed.
</pre></td></tr>
</table>
<p>
This indicates that the portage SELinux module is missing or damaged. Recent
Portage versions provide this module out-of-the-box, but the security contexts
of the necessary files might be wrong on your system. Try relabelling the files
of the portage package:
</p>
<a name="doc_chap5_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.2: Relabel all portage files</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
~# <span class="code-input">rlpkg portage</span>
</pre></td></tr>
</table>
<p class="secthead"><a name="loadpolicy"></a><a name="doc_chap5_sect2">I get 'FEATURES variable contains unknown value(s): loadpolicy'</a></p>
<p>
When running emerge, the following error is shown:
</p>
<a name="doc_chap5_pre3"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.3: Emerge error on loadpolicy</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
FEATURES variable contains unknown value(s): loadpolicy
</pre></td></tr>
</table>
<p>
This is a remnant of the older SELinux policy module set where policy packages
might require this FEATURE to be available. This has however since long been
removed from the tree.
</p>
<p>
Please update your profile to a recent SELinux profile (one ending with
<span class="path" dir="ltr">/selinux</span>) and make sure that <span class="path" dir="ltr">/etc/make.conf</span> does not
have <span class="code" dir="ltr">FEATURES="loadpolicy"</span> set.
</p>
<p class="secthead"><a name="conflicting_types"></a><a name="doc_chap5_sect3">During rlpkg I get 'conflicting specifications for ... and ..., using ...'</a></p>
<p>
When trying to relabel a package (<span class="code" dir="ltr">rlpkg packagename</span>) or system (<span class="code" dir="ltr">rlpkg
-a -r</span>) you get a message similar to the following:
</p>
<a name="doc_chap5_pre4"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.4: rlpkg complaining about conflicting specifications</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
filespec_add: conflicting specifications for /usr/bin/getconf and
/usr/lib64/misc/glibc/getconf/XBS5_LP64_OFF64, using
system_u:object_r:lib_t
</pre></td></tr>
</table>
<p>
This is most likely caused by hard linked files. Remember, SELinux uses the
extended attributes in the file system to store the security context of a file.
If two separate paths point to the same file using hard links (i.e. the files
share the same inode) then both files will have the same security context.
</p>
<p>
The solution depends on the particular case; in order of most likely to happen
and resolve:
</p>
<ol>
<li>
Although both files are the same, they are not used in the same context.
In such cases, it is recommended to remove one of the files and then copy
the other file back to the first (<span class="code" dir="ltr">rm B; cp A B</span>). This way, both
files have different inodes and can be labelled accordingly.
</li>
<li>
Both files are used for the same purpose; in this case, it might be better
to label the file which would not be labelled correctly (say a binary
somewhere in a <span class="path" dir="ltr">/usr/lib64</span> location) using <span class="code" dir="ltr">semanage</span>
(<span class="code" dir="ltr">semanage fcontext -a -t correct_domain_t /usr/lib64/path/to/file</span>)
</li>
</ol>
<p>
It is also not a bad idea to report (after verifying if it hasn't been reported
first) this on <a href="https://bugs.gentoo.org">Gentoo's bugzilla</a> so
that the default policies are updated accordingly.
</p>
<p class="secthead"><a name="portage_libsandbox"></a><a name="doc_chap5_sect4">During package installation, ld.so complains 'object 'libsandbox.so'
from LD_PRELOAD cannot be preloaded: ignored'</a></p>
<p>
During installation of a package, you might see the following error message:
</p>
<a name="doc_chap5_pre5"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.5: Error message during package installation</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
>> Installing (1 of 1) net-dns/host-991529
>>> Setting SELinux security labels
ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored.
</pre></td></tr>
</table>
<p>
This message should <span class="emphasis">only</span> occur after the <span class="emphasis">Setting SELinux security
labels</span> message. It happens because SELinux tells glibc to disable
<span class="code" dir="ltr">LD_PRELOAD</span> (and other environment variables that are considered
potentially harmful) during domain transitions. Here, portage calls the
<span class="code" dir="ltr">setfiles</span> command (part of a SELinux installation) and as such
transitions from portage_t to setfiles_t, which clears the environment
variable.
</p>
<p>
We believe that it is safer to trust the SELinux policy here (as setfiles runs
in its own confined domain anyhow) rather than updating the policy to allow
transitioning between portage_t to setfiles_t without clearing these
environment variables. Note that <span class="emphasis">libsandbox.so is not disabled during builds
and merges</span>, only during the activity where Portage labels the files it
just merged.
</p>
<p>
So the error is in our opinion cosmetic and can be ignored (but sadly not
hidden).
</p>
<p class="secthead"><a name="emergefails"></a><a name="doc_chap5_sect5">Emerge does not work, giving 'Permission denied: /etc/make.conf'</a></p>
<p>
This is to be expected if you are not using the <span class="code" dir="ltr">sysadm_r</span> role. Any
Portage related activity requires that you are in the <span class="code" dir="ltr">sysadm_r</span> role. To
transition to the role, first validate if you are currently known as
<span class="code" dir="ltr">staff_u</span> (or, if you added your own SELinux identities, a user that has
the permission to transition to the <span class="code" dir="ltr">sysadm_r</span> role). Then run <span class="code" dir="ltr">newrole
-r sysadm_r</span> to transition.
</p>
<a name="doc_chap5_pre6"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.6: Transitioning to sysadm_r</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
~$ <span class="code-input">emerge --info</span>
Permission denied: '/etc/make.conf'
~$ <span class="code-input">id -Z</span>
staff_u:staff_r:staff_t
~$ <span class="code-input">newrole -r sysadm_r</span>
Password: <span class="code-comment"># Enter your users' password</span>
</pre></td></tr>
</table>
<p>
This is also necessary if you logged on to your system as root but through SSH.
The default behavior is that SSH sets the lowest role for the particular user
when logged on. And you shouldn't allow remote root logins anyhow.
</p>
<p class="secthead"><a name="cronfails"></a><a name="doc_chap5_sect6">Cron fails to load in root's crontab with message '(root) ENTRYPOINT
FAILED (crontabs/root)'</a></p>
<p>
When you hit the mentioned error with a root crontab or an administrative
users' crontab, but not with a regular users' crontab, then check the context of
the crontab file:
</p>
<a name="doc_chap5_pre7"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.7: Check context of the crontab file</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
~# <span class="code-input">ls -Z /var/spool/cron/crontabs/root</span>
staff_u:object_r:user_cron_spool_t /var/spool/cron/crontabs/root
</pre></td></tr>
</table>
<p>
Next, check what the default context is for the given user (in this case, root)
when originating from the <span class="code" dir="ltr">crond_t</span> domain:
</p>
<a name="doc_chap5_pre8"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.8: Check default context for user root</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
~# <span class="code-input">getseuser root system_u:system_r:crond_t</span>
seuser: root, level (null)
Context 0 root:sysadm_r:cronjob_t
Context 1 root:staff_r:cronjob_t
</pre></td></tr>
</table>
<p>
As you can see, the default context is always for the <span class="code" dir="ltr">root</span> SELinux user.
However, the <span class="path" dir="ltr">/var/spool/cron/crontabs/root</span> file context in the
above example is for the SELinux user staff_u. Hence, cron will not be able to
read this file (the <span class="code" dir="ltr">user_cron_spool_t</span> type is a UBAC constrained one).
</p>
<p>
To fix this, change the user of the file to root:
</p>
<a name="doc_chap5_pre9"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.9: Change the SELinux user of the root crontab file</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
~# <span class="code-input">chcon -u root /var/spool/cron/crontabs/root</span>
</pre></td></tr>
</table>
<p>
Another fix would be to disable UBAC completely. This is accomplished with
<span class="code" dir="ltr">USE="-ubac"</span>.
</p>
<p class="secthead"><a name="missingdatum"></a><a name="doc_chap5_sect7">When querying the policy, I get 'ERROR: could not find datum for type ...'</a></p>
<p>
When using <span class="code" dir="ltr">seinfo</span> or <span class="code" dir="ltr">sesearch</span> to query the policy on the system,
you get errors similar to:
</p>
<a name="doc_chap5_pre10"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.10: Triggering the 'could not find datum' error</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
~# <span class="code-input">seinfo -tasterisk_t</span>
ERROR: could not find datum for type asterisk_t
</pre></td></tr>
</table>
<p>
This is most likely because your tools are using a newer binary policy to
enforce policy, but an older binary for querying. You can verify if this is the
case by listing the last modification time on the files:
</p>
<a name="doc_chap5_pre11"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.11: Checking last modification time of the policy files</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
~# <span class="code-input">ls -ltr /etc/selinux/strict/policy/policy.*</span>
</pre></td></tr>
</table>
<p>
The file modified last should be the same one as returned by checking
<span class="path" dir="ltr">/selinux/policyvers</span>:
</p>
<a name="doc_chap5_pre12"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.12: Checking the runtime policy version</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
~# <span class="code-input">cat /selinux/policyvers; echo</span>
24
</pre></td></tr>
</table>
<p>
If this is not the case (which is very likely since you are reading this FAQ
entry) then try forcing the utilities policy version to the correct version:
</p>
<a name="doc_chap5_pre13"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.13: Editing semanage.conf</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
~# <span class="code-input">vim /etc/selinux/semanage.conf</span>
<span class="code-comment"># Look for and uncomment the policy-version line and set it to the right version</span>
policy-version = <span class="code-input">24</span>
</pre></td></tr>
</table>
<table class="ncontent" width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td bgcolor="#ffffbb"><p class="note"><b>Important: </b>
If your system is upgrading its kernel, higher version(s) can be supported. In
this case, either unset the value again to automatically "jump" to a higher
version, or force set it to the higher version.
</p></td></tr></table>
<p class="secthead"><a name="recoverportage"></a><a name="doc_chap5_sect8">Portage fails to label files because "setfiles" does not work anymore</a></p>
<p>
Portage uses the <span class="code" dir="ltr">setfiles</span> command to set the labels of the files it
installs. However, that command is a dynamically linked executable, so any
update in its depending libraries (<span class="path" dir="ltr">libselinux.so</span>,
<span class="path" dir="ltr">libsepol.so</span>, <span class="path" dir="ltr">libaudit.so</span> and of course
<span class="path" dir="ltr">libc.so</span>) might cause for the application to fail. Gentoo's standard
solution (<span class="code" dir="ltr">revdep-rebuild</span>) will not work, since the tool will try to
rebuild policycoreutils, which will fail to install because Portage cannot set
the file labels.
</p>
<p>
The solution is to rebuild policycoreutils while disabling Portage's selinux
support, then label the installed files manually using <span class="code" dir="ltr">chcon</span>, based on
the feedback received from <span class="code" dir="ltr">matchpathcon</span>.
</p>
<a name="doc_chap5_pre14"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.14: Recovering from Portage installation failures</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">FEATURES="-selinux" emerge --oneshot policycoreutils</span>
# <span class="code-input">for FILE in $(qlist policycoreutils); do \
CONTEXT=$(matchpathcon -n ${FILE}); chcon ${CONTEXT} ${FILE}; done</span>
</pre></td></tr>
</table>
<p>
Now Portage will function properly again, labeling files as they should.
</p>
<p class="secthead"><a name="nosuid"></a><a name="doc_chap5_sect9">Applications do not transition on a nosuid-mounted partition</a></p>
<p>
If you have file systems mounted with the <span class="code" dir="ltr">nosuid</span> option, then
applications started from these file systems will not transition into their
appropriate domain. This is intentional.
</p>
<p>
So, a <span class="code" dir="ltr">passwd</span> binary, although correctly labeled <span class="emphasis">passwd_exec_t</span>,
will not transition into the <span class="emphasis">passwd_t</span> domain if the binary is stored on a
file system mounted with <span class="code" dir="ltr">nosuid</span>.
</p>
<p class="secthead"><a name="auth-run_init"></a><a name="doc_chap5_sect10">Why do I always need to re-authenticate when operating init scripts?</a></p>
<p>
When you, as an administrator, wants to launch or stop daemons, these activities
need to be done as <span class="code" dir="ltr">system_u:system_r</span>. Switching to this context set is a
highly privileged operation (since you are effectively leaving the user context
and entering a system context) and hence the default setup requires the user to
re-authenticate.
</p>
<p>
You can ask not to re-authenticate if you use PAM by editing
<span class="path" dir="ltr">/etc/pam.d/run_init</span> and adding the following line on top:
</p>
<a name="doc_chap5_pre15"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.15: Setup run_init pam configuration to allow root not to re-authenticate</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
auth sufficient pam_rootok.so
</pre></td></tr>
</table>
<p>
With this in place, you can now prepend your init script activities with
<span class="code" dir="ltr">run_init</span> and it will not ask for your password anymore:
</p>
<a name="doc_chap5_pre16"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.16: Using run_init</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">run_init rc-service local status</span>
Authenticating swift.
* status: started
</pre></td></tr>
</table>
<p class="secthead"><a name="initramfs"></a><a name="doc_chap5_sect11">How do I use SELinux with initramfs?</a></p>
<p>
We currently do not support booting in enforcing mode with an initramfs image
(but we are working on it). For the time being, boot in permissive mode. Once
booted, switch to enforcing mode (<span class="code" dir="ltr">setenforce 1</span>).
</p>
<p>
If you run SELinux on a production system and would not like to have attackers
be able to switch back to permissive mode (even when they would have the
necessary privileges otherwise), set the <span class="code" dir="ltr">secure_mode_policyload</span> boolean.
When enabled, enforcing mode cannot be disabled anymore (until you reboot).
</p>
<a name="doc_chap5_pre17"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing5.17: Toggling secure_mode_policyload</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
# <span class="code-input">setsebool secure_mode_policyload on</span>
</pre></td></tr>
</table>
<br><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="pebenito@gentoo.org?style=printable">Print</a></p></td></tr>
<tr><td class="topsep" align="center"><p class="alttext">Page updated February 26, 2012</p></td></tr>
<tr><td class="topsep" align="left"><p class="alttext"><b>Summary: </b>
Frequently Asked Questions on SELinux integration with Gentoo Hardened.
The FAQ is a collection of solutions found on IRC, mailinglist, forums or
elsewhere
</p></td></tr>
<tr><td align="left" class="topsep"><p class="alttext">
<a href="mailto:pebenito@gentoo.org" class="altlink"><b>Chris PeBenito</b></a>
<br><i>Author</i><br><br>
<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-2012 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