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
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
|
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux-faq.xml,v 1.2 2011/04/25 20:21:47 zorry Exp $ -->
<guide>
<title>Gentoo Hardened SELinux Frequently Asked Questions</title>
<author title="Author">
<mail link="pebenito@gentoo.org">Chris PeBenito</mail>
</author>
<author title="Author">
<mail link="sven.vermeulen@siphos.be">Sven Vermeulen</mail>
</author>
<abstract>
Frequently Asked Questions on SELinux integration with Gentoo Hardened.
The FAQ is a collection of solutions found on IRC, mailinglist, forums or
elsewhere
</abstract>
<version>20</version>
<date>2012-02-26</date>
<faqindex>
<title>Questions</title>
<section>
<title>Introduction</title>
<body>
<p>
Using SELinux requires administrators a more thorough knowledge of their
system and a good idea on how processes should behave. Next to the <uri
link="/proj/en/hardened/selinux/selinux-handbook.xml">Gentoo Hardened SELinux
handbook</uri>, 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>
</body>
</section>
</faqindex>
<chapter>
<title>General SELinux Support Questions</title>
<section id="features">
<title>Does SELinux enforce resource limits?</title>
<body>
<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>
</body>
</section>
<section id="grsecurity">
<title>Can I use SELinux with grsecurity (and PaX)?</title>
<body>
<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>
</body>
</section>
<section id="pie-ssp">
<title>Can I use SELinux and the hardened compiler (with PIE-SSP)?</title>
<body>
<p>
Definitely. We also suggest to use PaX to take full advantage of the PIE
features of the compiler.
</p>
</body>
</section>
<section id="rsbac">
<title>Can I use SELinux and RSBAC?</title>
<body>
<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>
<!--
If users are unclear, mention that you can compile both in and then try to
only enable one (configuration wise), but that this has little benefit on
the performance (since the hooks are there, the checks that are made are just
a bit different but due to caching, the overhead of having it enabled versus
disabled is small anyhow).
-->
</body>
</section>
<section id="filesystem">
<title>Can I use SELinux with any file system?</title>
<body>
<p>
SELinux requires access to a file's security context to operate properly.
To do so, SELinux uses <e>extended file attributes</e> 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>
</body>
</section>
<section id="nomultilib">
<title>Can I use SELinux with AMD64 no-multilib?</title>
<body>
<!-- FAQ might be removed in the future since it is now obvious -->
<p>
Yes, just use the <path>hardened/linux/amd64/no-multilib/selinux</path> profile
and you're all set.
</p>
</body>
</section>
<section id="ubac">
<title>What is UBAC exactly?</title>
<body>
<p>
UBAC, or <e>User Based Access Control</e>, introduces additional constraints
when using SELinux policy. Participating domains / types that are <e>both</e>
marked as a <c>ubac_constrained_type</c> (which is an attribute) will only
have the allowed privileges in effect if they both run with the same SELinux
user context.
</p>
<pre caption="Domains and their SELinux user context">
<comment># The SELinux allow rule</comment>
allow foo_t bar_t:file { read };
<comment># This will succeed:</comment>
staff_u:staff_r:foo_t reads file with type staff_u:object_r:bar_t
<comment># This will be prohibited:</comment>
user_u:user_r:foo_t reads file with type staff_u:object_r:bar_t
</pre>
<p>
Of course, this is not always the case. Besides the earlier mentioned
requirement that both types are <c>ubac_constrained_type</c>, if the source
domain is <c>sysadm_t</c>, then the constraint will not be in effect (the
<c>sysadm_t</c> domain is exempt from UBAC constraints). Also, if the source
or destination SELinux user is <c>system_u</c> then the constraint will also
not be in effect.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Using SELinux</title>
<section id="enable_selinux">
<title>How do I enable SELinux?</title>
<body>
<p>
This is explained in the <uri
link="/proj/en/hardened/selinux/selinux-handbook.xml">SELinux Handbook</uri>
in the chapter on <e>Using Gentoo/Hardened SELinux</e>.
</p>
</body>
</section>
<section id="switch_status">
<title>How do I switch between permissive and enforcing?</title>
<body>
<p>
The easiest way is to use the <c>setenforce</c> command. With <c>setenforce
0</c> you tell SELinux to run in permissive mode. Similarly, with
<c>setenforce 1</c> you tell SELinux to run in enforcing mode.
</p>
<p>
You can also add a kernel option <c>enforcing=0</c> or <c>enforcing=1</c>
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 <path>/etc/selinux/config</path>.
</p>
</body>
</section>
<section id="disable_selinux">
<title>How do I disable SELinux completely?</title>
<body>
<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 <path>/etc/selinux/config</path> and set <c>SELINUX=disabled</c>. Next,
reboot your system.
</p>
<impo>
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.
</impo>
</body>
</section>
<section id="matchcontext">
<title>How do I know which file context rule is used for a particular file?</title>
<body>
<p>
If you use the <c>matchpathcon</c> 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 <c>findcon</c>:
</p>
<pre caption="Using findcon">
~# <i>findcon /etc/selinux/strict/contexts/files/file_contexts -p /lib64/rc/init.d</i>
/.* 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>
<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 <c>semanage</c>), this does
not apply. Instead, tools like <c>restorecon</c> will take the <e>last</e> hit
within the locally added file contexts! You can check the content of the
locally added rules in <path>/etc/selinux/strict/contexts/files/file_contexts.local</path>
(substitute <path>strict</path> with your SELinux type).
</p>
</body>
</section>
<section id="localpolicy">
<title>How do I make small changes (additions) to the policy?</title>
<body>
<p>
If you are interested in the Gentoo Hardened SELinux development itself, please
have a look at the <uri link="/proj/en/hardened/selinux-development.xml">SELinux
Development Guide</uri> and other documentation linked from the <uri
link="/proj/en/hardened/selinux/index.xml">SELinux project page</uri>.
</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 <e>allow</e>
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
<path>fixlocal</path>, substitute with whatever name you like - but keep it
consistent. In the file (<path>fixlocal.te</path>) put in the following text
(again, substitute <path>fixlocal</path> with your chosen name):
</p>
<pre caption="fixlocal.te content">
policy_module(fixlocal, 1.0)
require {
<comment># Declarations of types, classes and permissions used</comment>
}
<comment># Declaration of policy rules</comment>
</pre>
<p>
In this file, you can add rules as you like. In the next example, we add three
rules:
</p>
<ol>
<li>
Allow <c>mozilla_t</c> the <c>execmem</c> privilege (based on a denial that
occurs when mozilla fails to start)
</li>
<li>
Allow <c>ssh_t</c> to connect to any port rather than just the SSH port
</li>
<li>
Allows the <c>user_t</c> domain to send messages directly to the system
logger
</li>
</ol>
<pre caption="fixlocal.te content">
policy_module(fixlocal, 1.0)
require {
type mozilla_t;
type ssh_t;
type user_t;
class process { execmem };
}
<comment># Grant mozilla the execmem privilege</comment>
allow mozilla_t self:process { execmem };
<comment># Allow SSH client to connect to any port (as provided by the user through the
# "ssh -p <portnum> ..." command)</comment>
corenet_tcp_connect_all_ports(ssh_t)
<comment># Allow the user_t domain to send messages to the system logger</comment>
logging_send_syslog_msg(user_t)
</pre>
<p>
If you need to provide raw allow statements (like the one above for the
<c>mozilla_t</c> domain), make sure that the type (<c>mozilla_t</c>),
class (<c>process</c>) and privilege (<c>execmem</c>) are mentioned in
the <c>require { ... }</c> paragraph.
</p>
<p>
When using interface names, make sure that the types (<c>ssh_t</c> and
<c>user_t</c>) are mentioned in the <c>require { ... }</c> paragraph.
</p>
<p>
To find the proper interface name (like <c>corenet_tcp_connect_all_ports</c>
above), you can either look for it in the <uri
link="http://oss.tresys.com/docs/refpolicy/api/">SELinux Reference Policy
API</uri> online or, if <c>sec-policy/selinux-base-policy</c> is built with the
<e>doc</e> USE flag, in <path>/usr/share/doc/selinux-base-policy-.*/html</path>.
Of course, you can also ask for help in <c>#gentoo-hardened</c> on
irc.freenode.net, the mailinglist, forums, etc. to find the proper rules and
statements for your case.
</p>
</body>
</section>
</chapter>
<chapter>
<title>SELinux Kernel Error Messages</title>
<section id="register_security">
<title>I get a register_security error message when booting</title>
<body>
<p>
During boot-up, the following message pops up:
</p>
<pre caption="Kernel message on register_security">
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>
<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>
</body>
</section>
<section id="permission_not_defined">
<title>I get a 'Permission ... in class ... not defined' message during booting</title>
<body>
<p>
During boot-up, the following message is shown:
</p>
<pre caption="Kernel message on undefined permission(s)">
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>
<p>
This means that the Linux kernel that you are booting supports permissions that
are not defined in the policy (as offered through the
<c>sec-policy/selinux-base-policy</c> 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>
</body>
</section>
</chapter>
<chapter>
<title>SELinux and Gentoo</title>
<section id="no_module">
<title>I get a missing SELinux module error when using emerge</title>
<body>
<p>
When trying to use <c>emerge</c>, the following error message is displayed:
</p>
<pre caption="Error message from emerge on the SELinux module">
!!! SELinux module not found. Please verify that it was installed.
</pre>
<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>
<pre caption="Relabel all portage files">
~# <i>rlpkg portage</i>
</pre>
</body>
</section>
<section id="loadpolicy">
<title>I get 'FEATURES variable contains unknown value(s): loadpolicy'</title>
<body>
<p>
When running emerge, the following error is shown:
</p>
<pre caption="Emerge error on loadpolicy">
FEATURES variable contains unknown value(s): loadpolicy
</pre>
<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
<path>/selinux</path>) and make sure that <path>/etc/make.conf</path> does not
have <c>FEATURES="loadpolicy"</c> set.
</p>
</body>
</section>
<section id="conflicting_types">
<title>During rlpkg I get 'conflicting specifications for ... and ..., using ...'</title>
<body>
<p>
When trying to relabel a package (<c>rlpkg packagename</c>) or system (<c>rlpkg
-a -r</c>) you get a message similar to the following:
</p>
<pre caption="rlpkg complaining about conflicting specifications">
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>
<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 (<c>rm B; cp A B</c>). 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 <path>/usr/lib64</path> location) using <c>semanage</c>
(<c>semanage fcontext -a -t correct_domain_t /usr/lib64/path/to/file</c>)
</li>
</ol>
<p>
It is also not a bad idea to report (after verifying if it hasn't been reported
first) this on <uri link="https://bugs.gentoo.org">Gentoo's bugzilla</uri> so
that the default policies are updated accordingly.
</p>
</body>
</section>
<section id="portage_libsandbox">
<title>During package installation, ld.so complains 'object 'libsandbox.so'
from LD_PRELOAD cannot be preloaded: ignored'</title>
<body>
<p>
During installation of a package, you might see the following error message:
</p>
<pre caption="Error message during package installation">
>> 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>
<p>
This message should <e>only</e> occur after the <e>Setting SELinux security
labels</e> message. It happens because SELinux tells glibc to disable
<c>LD_PRELOAD</c> (and other environment variables that are considered
potentially harmful) during domain transitions. Here, portage calls the
<c>setfiles</c> 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 <e>libsandbox.so is not disabled during builds
and merges</e>, 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>
</body>
</section>
<section id="emergefails">
<title>Emerge does not work, giving 'Permission denied: /etc/make.conf'</title>
<body>
<p>
This is to be expected if you are not using the <c>sysadm_r</c> role. Any
Portage related activity requires that you are in the <c>sysadm_r</c> role. To
transition to the role, first validate if you are currently known as
<c>staff_u</c> (or, if you added your own SELinux identities, a user that has
the permission to transition to the <c>sysadm_r</c> role). Then run <c>newrole
-r sysadm_r</c> to transition.
</p>
<pre caption="Transitioning to sysadm_r">
~$ <i>emerge --info</i>
Permission denied: '/etc/make.conf'
~$ <i>id -Z</i>
staff_u:staff_r:staff_t
~$ <i>newrole -r sysadm_r</i>
Password: <comment># Enter your users' password</comment>
</pre>
<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>
</body>
</section>
<section id="cronfails">
<title>Cron fails to load in root's crontab with message '(root) ENTRYPOINT
FAILED (crontabs/root)'</title>
<body>
<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>
<pre caption="Check context of the crontab file">
~# <i>ls -Z /var/spool/cron/crontabs/root</i>
staff_u:object_r:user_cron_spool_t /var/spool/cron/crontabs/root
</pre>
<p>
Next, check what the default context is for the given user (in this case, root)
when originating from the <c>crond_t</c> domain:
</p>
<pre caption="Check default context for user root">
~# <i>getseuser root system_u:system_r:crond_t</i>
seuser: root, level (null)
Context 0 root:sysadm_r:cronjob_t
Context 1 root:staff_r:cronjob_t
</pre>
<p>
As you can see, the default context is always for the <c>root</c> SELinux user.
However, the <path>/var/spool/cron/crontabs/root</path> file context in the
above example is for the SELinux user staff_u. Hence, cron will not be able to
read this file (the <c>user_cron_spool_t</c> type is a UBAC constrained one).
</p>
<p>
To fix this, change the user of the file to root:
</p>
<pre caption="Change the SELinux user of the root crontab file">
~# <i>chcon -u root /var/spool/cron/crontabs/root</i>
</pre>
<p>
Another fix would be to disable UBAC completely. This is accomplished with
<c>USE="-ubac"</c>.
</p>
</body>
</section>
<section id="missingdatum">
<title>When querying the policy, I get 'ERROR: could not find datum for type ...'</title>
<body>
<p>
When using <c>seinfo</c> or <c>sesearch</c> to query the policy on the system,
you get errors similar to:
</p>
<pre caption="Triggering the 'could not find datum' error">
~# <i>seinfo -tasterisk_t</i>
ERROR: could not find datum for type asterisk_t
</pre>
<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>
<pre caption="Checking last modification time of the policy files">
~# <i>ls -ltr /etc/selinux/strict/policy/policy.*</i>
</pre>
<p>
The file modified last should be the same one as returned by checking
<path>/selinux/policyvers</path>:
</p>
<pre caption="Checking the runtime policy version">
~# <i>cat /selinux/policyvers; echo</i>
24
</pre>
<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>
<pre caption="Editing semanage.conf">
~# <i>vim /etc/selinux/semanage.conf</i>
<comment># Look for and uncomment the policy-version line and set it to the right version</comment>
policy-version = <i>24</i>
</pre>
<impo>
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.
</impo>
</body>
</section>
<section id="recoverportage">
<title>Portage fails to label files because "setfiles" does not work anymore</title>
<body>
<p>
Portage uses the <c>setfiles</c> 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 (<path>libselinux.so</path>,
<path>libsepol.so</path>, <path>libaudit.so</path> and of course
<path>libc.so</path>) might cause for the application to fail. Gentoo's standard
solution (<c>revdep-rebuild</c>) 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 <c>chcon</c>, based on
the feedback received from <c>matchpathcon</c>.
</p>
<pre caption="Recovering from Portage installation failures">
# <i>FEATURES="-selinux" emerge --oneshot policycoreutils</i>
# <i>for FILE in $(qlist policycoreutils); do \
CONTEXT=$(matchpathcon -n ${FILE}); chcon ${CONTEXT} ${FILE}; done</i>
</pre>
<p>
Now Portage will function properly again, labeling files as they should.
</p>
</body>
</section>
<section id="nosuid">
<title>Applications do not transition on a nosuid-mounted partition</title>
<body>
<p>
If you have file systems mounted with the <c>nosuid</c> option, then
applications started from these file systems will not transition into their
appropriate domain. This is intentional.
</p>
<p>
So, a <c>passwd</c> binary, although correctly labeled <e>passwd_exec_t</e>,
will not transition into the <e>passwd_t</e> domain if the binary is stored on a
file system mounted with <c>nosuid</c>.
</p>
</body>
</section>
<section id="auth-run_init">
<title>Why do I always need to re-authenticate when operating init scripts?</title>
<body>
<p>
When you, as an administrator, wants to launch or stop daemons, these activities
need to be done as <c>system_u:system_r</c>. 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
<path>/etc/pam.d/run_init</path> and adding the following line on top:
</p>
<pre caption="Setup run_init pam configuration to allow root not to re-authenticate">
auth sufficient pam_rootok.so
</pre>
<p>
With this in place, you can now prepend your init script activities with
<c>run_init</c> and it will not ask for your password anymore:
</p>
<pre caption="Using run_init">
# <i>run_init rc-service local status</i>
Authenticating swift.
* status: started
</pre>
</body>
</section>
<section id="initramfs">
<title>How do I use SELinux with initramfs?</title>
<body>
<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 (<c>setenforce 1</c>).
</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 <c>secure_mode_policyload</c> boolean.
When enabled, enforcing mode cannot be disabled anymore (until you reboot).
</p>
<pre caption="Toggling secure_mode_policyload">
# <i>setsebool secure_mode_policyload on</i>
</pre>
</body>
</section>
</chapter>
</guide>
|
GitWeb