Bug 431202 - Wrong security labels on /var/named/chroot/dev/*
Wrong security labels on /var/named/chroot/dev/*
Status: CLOSED DUPLICATE of bug 253537
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: bind (Show other bugs)
5.2
All Linux
low Severity low
: rc
: ---
Assigned To: Adam Tkac
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-01 09:54 EST by Milan Zazrivec
Modified: 2013-04-30 19:38 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-08 04:48:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Milan Zazrivec 2008-02-01 09:54:01 EST
Description of problem:
RHEL5.2-Client-20080201.nightly anaconda installation:
null, random and zero device nodes in /var/named/chroot/dev have
wrong security labels.

Version-Release number of selected component (if applicable):
bind-chroot-9.3.4-3.P1.el5

How reproducible:
Always

Steps to Reproduce:
1. Install RHEL5.2-Client-20080201.nightly (or anything beyond installable) with
   bind-chroot package included
2. Reboot
3. ls -lZ /var/named/chroot/dev/*
  
Actual results:
crw-rw----  root named system_u:object_r:named_conf_t   null
crw-rw----  root named system_u:object_r:named_conf_t   random
crw-rw----  root named system_u:object_r:named_conf_t   zero

Expected results:
crw-rw----  root named system_u:object_r:null_device_t  null
crw-rw----  root named system_u:object_r:random_device_t random
crw-rw----  root named system_u:object_r:zero_device_t  zero

Additional info:
Wrong security labels on these device nodes cause an avc denial when starting
named-chroot:

avc:  denied  { getattr } for  pid=3254 comm="named" path="/dev/random" dev=dm-0
ino=4821839 scontext=root:system_r:named_t:s0
tcontext=system_u:object_r:named_conf_t:s0 tclass=chr_fil
e
Comment 1 Adam Tkac 2008-02-04 11:52:56 EST
Hm, in the end it looks that problem is also in selinux-policy. Problem is fixed
on bind side by bug #253537.

- Install RHEL5 and during installation (when bind and policycoreutils are
installed) try run "restorecon /mnt/sysimage/var/named/chroot/dev/*"
- context is bad but when I run for example "restorecon /mnt/sysimage/bin/pwd"
context of pwd is good

Reassigning to selinux-policy to next inspection
Comment 2 Daniel Walsh 2008-02-04 16:20:28 EST
So anaconda install ends up with the wrong context, while installing the machine
after anaconda gets it right?

If you execute restorecon  on the directory, does it fix the labels?
Comment 3 Adam Tkac 2008-02-05 11:06:04 EST
(In reply to comment #2)
> So anaconda install ends up with the wrong context, while installing the machine
> after anaconda gets it right?
> 
> If you execute restorecon  on the directory, does it fix the labels?

When installation ends /var/named/chroot/dev/* files has wrong context. Only
when you reboot after installation and fix labels manually it works as expected
Comment 4 Daniel Walsh 2008-02-05 11:23:30 EST
Could you check to see if bind-chroot is being installed in anaconda before
selinux-policy-targeted, which would cause this problem.
Comment 5 Milan Zazrivec 2008-02-05 11:32:39 EST
bind-chroot actually does install before selinux-policy-targeted
(@everything installation).
Comment 6 Daniel Walsh 2008-02-05 15:06:11 EST
That is what the problem is.  There is no good way for us to fix this.  If you
require selinux-policy-targeted, it would work, but that is not a good idea, for
people who do not want policy installed.  You could add a restorecon to your
init scripts, So everytime the bind service starts it fixes the context on the
chroot directories.
Comment 7 Adam Tkac 2008-02-06 06:02:18 EST
Requiring selinux-* is bad idea. Also restorecon in initscript is bad but seems
like only one possible solution. Reassigning back to bind
Comment 8 Adam Tkac 2008-02-08 04:48:25 EST

*** This bug has been marked as a duplicate of 253537 ***
Comment 9 Adam Tkac 2008-02-13 07:01:29 EST
(In reply to comment #6)
> That is what the problem is.  There is no good way for us to fix this.  If you
> require selinux-policy-targeted, it would work, but that is not a good idea, for
> people who do not want policy installed.  You could add a restorecon to your
> init scripts, So everytime the bind service starts it fixes the context on the
> chroot directories.

Tomas Mraz point me to better solution. In the end I used %posttrans script in
rpm and it also fixes the problem and solution is clearer

Note You need to log in before you can comment on or make changes to this bug.