Bug 492567 - restorecon breaks selinux contexts in /var/named/chroot/proc (which is bind mounted to /proc so breaks that too)
Summary: restorecon breaks selinux contexts in /var/named/chroot/proc (which is bind m...
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy-targeted
Version: 5.2
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Daniel Walsh
QA Contact: BaseOS QE
Depends On:
TreeView+ depends on / blocked
Reported: 2009-03-27 14:00 UTC by Kieran Clancy
Modified: 2012-10-15 14:00 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-09-02 08:00:04 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
CentOS 3449 0 None None None Never
Red Hat Product Errata RHBA-2009:1242 0 normal SHIPPED_LIVE selinux-policy bug fix update 2009-09-01 08:32:34 UTC

Description Kieran Clancy 2009-03-27 14:00:41 UTC
Description of problem:
The /proc mount is set up to not be touched by restorecon. However, /var/named/chroot/proc gets set to system_u:object_r:named_conf_t:s0, which then makes the main /proc filesystem a complete mess and causes hundreds of SELinux denials from processes accessing their own file descriptors and sockets.

I think there needs to be a '<<none>>' rule for /var/named/chroot/proc(/.*)?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. setenforce 0 (without this it may still happen, but this is the current state of my system while I sort out some other issues on the system.)
2. install and run bind (named)
3. restorecon -R -v /var/named/chroot
4. ls -aldZ /proc /proc/acpi
Actual results:
dr-xr-xr-x  root root system_u:object_r:named_conf_t   /proc
dr-xr-xr-x  root root system_u:object_r:named_conf_t   /proc/acpi

Expected results:
dr-xr-xr-x  root root system_u:object_r:proc_t:s0      /proc
dr-xr-xr-x  root root system_u:object_r:proc_t:s0      /proc/acpi

Current work-around attempt - I haven't been able to safely restart the machine yet, so I don't know if it really works, but I don't see why it won't:

module namedprocfix 1.0;
require {
  type file_t;

/var/named/chroot/proc(/.*)?	<<none>>

$ checkmodule -m -M -o namedprocfix.mod namedprocfix.te
$ semodule_package -o namedprocfix.pp -m namedprocfix.mod -f namedprocfix.fc
$ semodule -i namedprocfix.pp

Here's the default file context rules relevant to this issue:
[root@gateway selinux]# semanage fcontext -l | grep ^/proc
/proc/.* all files <<None>>
/proc directory <<None>>

[root@gateway selinux]# semanage fcontext -l | grep ^/var/named/chroot
/var/named/chroot(/.*)? all files system_u:object_r:named_conf_t:s0
/var/named/chroot/etc(/.*)? all files system_u:object_r:named_conf_t:s0
/var/named/chroot/var/tmp(/.*)? all files system_u:object_r:named_cache_t:s0
/var/named/chroot/var/named(/.*)? all files system_u:object_r:named_zone_t:s0
/var/named/chroot/var/run/dbus(/.*)? all files system_u:object_r:system_dbusd_var_run_t:s0
/var/named/chroot/var/run/named.* all files system_u:object_r:named_var_run_t:s0
/var/named/chroot/var/named/data(/.*)? all files system_u:object_r:named_cache_t:s0
/var/named/chroot/var/named/slaves(/.*)? all files system_u:object_r:named_cache_t:s0
/var/named/chroot/var/log directory system_u:object_r:var_log_t:s0
/var/named/chroot/dev/zero character device system_u:object_r:zero_device_t:s0
/var/named/chroot/dev/null character device system_u:object_r:null_device_t:s0
/var/named/chroot/dev/random character device system_u:object_r:random_device_t:s0
/var/named/chroot/etc/rndc\.key regular file system_u:object_r:dnssec_t:s0
/var/named/chroot/var/named/named\.ca regular file system_u:object_r:named_conf_t:s0

Comment 1 Daniel Walsh 2009-03-27 19:12:26 UTC
Fixed in selinux-policy-2.4.6-219.el5
Preview to U4 policy is available on 

Comment 8 errata-xmlrpc 2009-09-02 08:00:04 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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