Bug 431202 - Wrong security labels on /var/named/chroot/dev/*
Summary: Wrong security labels on /var/named/chroot/dev/*
Keywords:
Status: CLOSED DUPLICATE of bug 253537
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: bind
Version: 5.2
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Adam Tkac
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-02-01 14:54 UTC by Milan Zázrivec
Modified: 2013-04-30 23:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-02-08 09:48:25 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Milan Zázrivec 2008-02-01 14:54:01 UTC
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 16:52:56 UTC
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 21:20:28 UTC
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 16:06:04 UTC
(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 16:23:30 UTC
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 Zázrivec 2008-02-05 16:32:39 UTC
bind-chroot actually does install before selinux-policy-targeted
(@everything installation).

Comment 6 Daniel Walsh 2008-02-05 20:06:11 UTC
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 11:02:18 UTC
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 09:48:25 UTC

*** This bug has been marked as a duplicate of 253537 ***

Comment 9 Adam Tkac 2008-02-13 12:01:29 UTC
(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.