Bug 163977 - ypbind denied read access to yp.conf
ypbind denied read access to yp.conf
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-22 12:09 EDT by Ralf Corsepius
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 1.27.1-2.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-20 20:08:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
As requested output of the script below (1.64 KB, text/plain)
2005-07-26 14:57 EDT, Ralf Corsepius
no flags Details

  None (edit)
Description Ralf Corsepius 2005-07-22 12:09:15 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050719 Fedora/1.7.10-1.5.1

Description of problem:
During boot up, I am seeing selinux denied messages:

# dmesg | grep denied
audit(1122047077.014:2): avc:  denied  { read } for  pid=1996 comm="ypbind" name="yp.conf" dev=hda2 ino=229074 scontext=system_u:system_r:ypbind_t tcontext=system_u:object_r:etc_runtime_t tclass=file
audit(1122047077.014:3): avc:  denied  { getattr } for  pid=1996 comm="ypbind" name="yp.conf" dev=hda2 ino=229074 scontext=system_u:system_r:ypbind_t tcontext=system_u:object_r:etc_runtime_t tclass=file
audit(1122047106.425:4): avc:  denied  { read } for  pid=2316 comm="ypbind" name="yp.conf" dev=hda2 ino=229074 scontext=system_u:system_r:ypbind_t tcontext=system_u:object_r:etc_runtime_t tclass=file
audit(1122047106.425:5): avc:  denied  { getattr } for  pid=2316 comm="ypbind" name="yp.conf" dev=hda2 ino=229074 scontext=system_u:system_r:ypbind_t tcontext=system_u:object_r:etc_runtime_t tclass=file

AFAIU, SELinux is dening ypbind read access to yp.conf.


Version-Release number of selected component (if applicable):
selinux-policy-targeted-1.25.2-4

How reproducible:
Always

Steps to Reproduce:
Boot a machine configured as dhcp-client and ypclient, with selinux-policy-targeted enabled.


Additional info:

Apparent cause seems to be dhclient-script's interaction with SELinux and ypbind.

After booting:
# ls -lZ /etc/yp.conf*
-rw-r--r--  root     root     system_u:object_r:etc_runtime_t  /etc/yp.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t    /etc/yp.conf.predhclient

# restorecon /etc/yp.conf*

# ls -lZ /etc/yp.conf*
-rw-r--r--  root     root     system_u:object_r:net_conf_t     /etc/yp.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t     /etc/yp.conf.predhclient

AFAIS, this issue could be related to PR 155143 and PR 153244
Comment 1 Daniel Walsh 2005-07-22 13:20:25 EDT
Is dhclient mislabed?  

dhclient should be creating yp.conf as net_conf_t.

ls -lZ /sbin/dhclient
-rwxr-xr-x  root     root     system_u:object_r:dhcpc_exec_t   /sbin/dhclient

Dan
Comment 2 Ralf Corsepius 2005-07-22 13:45:24 EDT
Nope. This is what I have:

# ls -lZ /sbin/dhclient
-rwxr-xr-x  root     root     system_u:object_r:dhcpc_exec_t   /sbin/dhclient

# rpm -V dhclient
[nothing]

But note this:

# ls -lZ *dhc*
-rw-r--r--  root     root     system_u:object_r:dhcp_etc_t     dhclient.conf
-rw-r--r--  root     root     system_u:object_r:dhcp_etc_t     dhclient-eth1.conf
-rw-r--r--  root     root     system_u:object_r:etc_runtime_t 
resolv.conf.predhclient
-rw-r--r--  root     root     system_u:object_r:net_conf_t     yp.conf.predhclient

# restorecon /etc/*dhc*

# ls -lZ *dhc*
-rw-r--r--  root     root     system_u:object_r:dhcp_etc_t     dhclient.conf
-rw-r--r--  root     root     system_u:object_r:dhcp_etc_t     dhclient-eth1.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t    
resolv.conf.predhclient
-rw-r--r--  root     root     system_u:object_r:net_conf_t     yp.conf.predhclient

When rebooting after the restorecon, the deny'ed message appear again and the
label are back to their broken state.
Comment 3 Daniel Walsh 2005-07-22 14:00:21 EDT
Looks like some transition is not happening or someone other than dhclient is
creating the file.  Is your resolv.conf created with net_conf_t?
Comment 4 Ralf Corsepius 2005-07-22 15:29:40 EDT
(In reply to comment #3)
> Looks like some transition is not happening or someone other than dhclient is
> creating the file.
ifup*, Kudzu or who else is it to copy/link
/etc/sysconfig/networking/*/*/resolv.conf?


> Is your resolv.conf created with net_conf_t?

Yes, seems so:

# ls -lZ /etc/resolv.conf /etc/sysconfig/networking/*/*/resolv.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t     /etc/resolv.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t    
/etc/sysconfig/networking/profiles/default/resolv.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t    
/etc/sysconfig/networking/profiles/Local/resolv.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t    
/etc/sysconfig/networking/profiles/Standalone/resolv.conf

In this case, */Local/resolv.conf and /etc/resolv.conf are hard-linked.
# ls -li /etc/resolv.conf /etc/sysconfig/networking/*/*/resolv.conf
4694694 -rw-r--r--  2 root root 82 Jul 22 19:29 /etc/resolv.conf
 508580 -rw-r--r--  1 root root 82 Jun 20 13:58
/etc/sysconfig/networking/profiles/default/resolv.conf
4694694 -rw-r--r--  2 root root 82 Jul 22 19:29
/etc/sysconfig/networking/profiles/Local/resolv.conf
4562328 -rw-r--r--  1 root root 82 Jun 20 13:58
/etc/sysconfig/networking/profiles/Standalone/resolv.conf
Comment 5 Daniel Walsh 2005-07-25 09:33:04 EDT
Jason do you have any ideas?

Dan
Comment 6 Ralf Corsepius 2005-07-25 09:52:12 EDT
FYI:

1. resolv.conf and yp.conf aren't the only files being affected:

# fixfiles check /etc
# reboot
# fixfiles check /etc
/sbin/restorecon reset /etc/X11/xorg.conf.backup-nvidia-glx context
system_u:object_r:etc_runtime_t->system_u:object_r:etc_t
/sbin/restorecon reset /etc/X11/xorg.conf context
system_u:object_r:etc_runtime_t->system_u:object_r:etc_t
/sbin/restorecon reset /etc/yp.conf context
system_u:object_r:etc_runtime_t->system_u:object_r:net_conf_t
/sbin/restorecon reset /etc/resolv.conf.predhclient context
system_u:object_r:etc_runtime_t->system_u:object_r:net_conf_t

2. I am able to reproduce this issue deterministically on one machine, but am
not able to reproduce it on 2 others with very similar configuration.

The main difference between the affected machine and the others, is the affected
machine using several networking profiles (It's my notebook), while the others
are stationary machines and only use single network profile.
Comment 7 Jason Vas Dias 2005-07-25 10:14:28 EDT
With selinux-policy-targeted-1.25.2-5 in Enforcing mode on Rawhide, all of 
/etc/{resolv.conf*,yp.conf*} end up with file context 
'system_u:object_r:net_conf_t' after a dhclient session. 
dhclient does NO "restorecon"s or explicit manipulation of file contexts
anymore - it's all up to the SELinux autotrans magic to ensure that the
file contexts of files created by dhclient-script are correct . 
Other applications may write yp.conf: authconfig, 
system-config-network .
Perhaps trying this might help clarify things :
# ifdown
# ls -lZ /etc/{resolv*,yp.conf*}
# ifconfig eth0 up
# dhclient -lf /var/lib/dhcp/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid
eth0
# ls -lZ /etc/{resolv*,yp.conf*}
and append the output of the above commands to this bug report.

Comment 8 Ralf Corsepius 2005-07-26 14:57:05 EDT
Created attachment 117166 [details]
As requested output of the script below


#!/bin/sh -x
ifdown eth1
ls -lZ /etc/{resolv.conf*,yp.conf*};
ifconfig eth1 up
dhclient -lf /var/lib/dhcp/dhclient-eth1.leases \
-pf /var/run/dhclient-eth1.pid
ls -lZ /etc/{resolv.conf*,yp.conf*}

Note: For reasons unknown to me (probably a bug), kudzu insists on using eth1
for the NIC.
Comment 9 Jason Vas Dias 2005-07-26 15:18:15 EDT
OK, I think I see the problem now - after the ifup, the yp.conf 
files created by dhclient-script have this context:
-rw-r--r--  root     root     root:object_r:net_conf_t         /etc/yp.conf
-rw-r--r--  root     root     system_u:object_r:etc_runtime_t 
/etc/yp.conf.predhclient

During an 'ifdown', dhclient-script is run in 'STOP' mode directly by 
  /etc/sysconfig/network-scripts/ifdown-eth
NOT by dhclient, and it replaces the /etc/yp.conf written during the 'ifup'
(which does have the correct context) with /etc/yp.conf.predhclient (which
does not) and restarts the ypbind service; ypbind will then not have correct
permission for yp.conf.

So I think the "permission denied" errors occur on an ifdown, not on an
ifup - can you confirm ?

You can probably stop this problem by doing an ifdown and then a 
'restorecon /etc/yp.conf; service ypbind restart' . After the yp.conf
with correct context is in place after the DHCP interface is down, 
subsequent ifup/ifdown sequences will restore the file with the correct
context, and the problem should not re-occur.

Dan -
  Should dhclient-script be doing a 'restorecon /etc/yp.conf' in STOP mode ?
  We did decide to take all the restorecons out earlier .
  Is this caused by the fact that in STOP mode, dhclient-script is not run
  by dhclient, so does not inherit the correct context for auto-transitioning?
  If so, could we fix it by making dhclient-script get the correct context when
  run by ifdown-eth ?
Comment 10 Daniel Walsh 2005-07-26 15:27:07 EDT
No.  The problem is the yp.conf.pre* got created incorrectly at one point.

restorecon -v /etc/yp.conf*  

Should fix the problem

Dan
Comment 11 Ralf Corsepius 2005-07-26 15:54:14 EDT
(In reply to comment #9)

> So I think the "permission denied" errors occur on an ifdown, not on an
> ifup - can you confirm ?

No, these appear during "service ypbind start".
Comment 12 Ralf Corsepius 2005-07-26 15:59:08 EDT
(In reply to comment #10)
> No.  The problem is the yp.conf.pre* got created incorrectly at one point.
Yes, during bootup, by some of the if* scripts.
 
> restorecon -v /etc/yp.conf*  
>
> Should fix the problem
/etc/yp.conf* are being overwritten during bootup, so this doesn't help.
Comment 13 Daniel Walsh 2005-08-25 15:48:36 EDT
By whom? What? Where?

If you do a 
restorecon -v /etc/yp.conf* 
reboot
What does the /etc/yp.conf end up with for a context?

Comment 14 Ralf Corsepius 2005-08-25 23:21:07 EDT
(In reply to comment #13)
> By whom? What? Where?
I wish I knew! It's dhcp-client*, if* and may-be kudzu interacting.

> If you do a 
> restorecon -v /etc/yp.conf* 
> reboot
> What does the /etc/yp.conf end up with for a context?

# ls -lZ /etc/yp.conf*
-rw-r--r--  root     root     system_u:object_r:etc_runtime_t  /etc/yp.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t    
/etc/yp.conf.predhclient
# restorecon -v /etc/yp.conf*
restorecon reset /etc/yp.conf context
system_u:object_r:etc_runtime_t->system_u:object_r:net_conf_t
# ls -lZ /etc/yp.conf*
-rw-r--r--  root     root     system_u:object_r:net_conf_t     /etc/yp.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t    
/etc/yp.conf.predhclient

# reboot
[..]
# ls -lZ /etc/yp.conf*
-rw-r--r--  root     root     system_u:object_r:etc_runtime_t  /etc/yp.conf
-rw-r--r--  root     root     system_u:object_r:net_conf_t    
/etc/yp.conf.predhclient
Comment 15 Daniel Walsh 2005-09-19 16:20:23 EDT
Fixed in selinux-policy-*-1.27.1-2.1

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