Bug 492567 - restorecon breaks selinux contexts in /var/named/chroot/proc (which is bind mounted to /proc so breaks that too)
restorecon breaks selinux contexts in /var/named/chroot/proc (which is bind m...
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy-targeted (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2009-03-27 10:00 EDT by Kieran Clancy
Modified: 2012-10-15 10:00 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 04:00:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
CentOS 3449 None None None Never

  None (edit)
Description Kieran Clancy 2009-03-27 10:00:41 EDT
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 15:12:26 EDT
Fixed in selinux-policy-2.4.6-219.el5
Preview to U4 policy is available on 
Comment 8 errata-xmlrpc 2009-09-02 04:00:04 EDT
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.