Bug 446633 - SELinux is preventing cp (dhcpc_t) "write" to ./resolv.conf.predhclient.eth0 (etc_t)
Summary: SELinux is preventing cp (dhcpc_t) "write" to ./resolv.conf.predhclient.eth0 ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 9
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 446634 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-15 14:07 UTC by David Hislop
Modified: 2008-05-24 13:17 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-16 19:55:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description David Hislop 2008-05-15 14:07:54 UTC
Description of problem:
Newly installed Fedora 9; configured wired and wireless adaptors to be managed
by Network Manager, restarted network service; received SELinux error.

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

How reproducible:
Every time

Steps to Reproduce:
1. As above
2.
3.
  
Actual results:

===== Copy from setroubleshoot starts

Summary:

SELinux is preventing cp (dhcpc_t) "write" to ./resolv.conf.predhclient.eth0
(etc_t).

Detailed Description:

SELinux is preventing cp (dhcpc_t) "write" to ./resolv.conf.predhclient.eth0
(etc_t). The SELinux type etc_t, is a generic type for all files in the
directory and very few processes (SELinux Domains) are allowed to write to this
SELinux type. This type of denial usual indicates a mislabeled file. By default
a file created in a directory has the gets the context of the parent directory,
but SELinux policy has rules about the creation of directories, that say if a
process running in one SELinux Domain (D1) creates a file in a directory with a
particular SELinux File Context (F1) the file gets a different File Context
(F2). The policy usually allows the SELinux Domain (D1) the ability to write,
unlink, and append on (F2). But if for some reason a file
(./resolv.conf.predhclient.eth0) was created with the wrong context, this domain
will be denied. The usual solution to this problem is to reset the file context
on the target file, restorecon -v './resolv.conf.predhclient.eth0'. If the file
context does not change from etc_t, then this is probably a bug in policy.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against the selinux-policy package. If it does change, you can try your
application again to see if it works. The file context could have been
mislabeled by editing the file or moving the file from a different directory, if
the file keeps getting mislabeled, check the init scripts to see if they are
doing something to mislabel the file.

Allowing Access:

You can attempt to fix file context by executing restorecon -v
'./resolv.conf.predhclient.eth0'

Fix Command:

restorecon './resolv.conf.predhclient.eth0'

Additional Information:

Source Context                unconfined_u:system_r:dhcpc_t:s0
Target Context                unconfined_u:object_r:etc_t:s0
Target Objects                ./resolv.conf.predhclient.eth0 [ file ]
Source                        cp
Source Path                   /bin/cp
Port                          <Unknown>
Host                          slate
Source RPM Packages           coreutils-6.10-18.fc9
Target RPM Packages           
Policy RPM                    selinux-policy-3.3.1-42.fc9
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   mislabeled_file
Host Name                     slate
Platform                      Linux slate 2.6.25-14.fc9.i686 #1 SMP Thu May 1
                              06:28:41 EDT 2008 i686 i686
Alert Count                   3
First Seen                    Thu 15 May 2008 08:07:32 PM EST
Last Seen                     Thu 15 May 2008 11:46:54 PM EST
Local ID                      955207c4-52a1-4f89-b638-8cc08395d507
Line Numbers                  

Raw Audit Messages            

host=slate type=AVC msg=audit(1210859214.167:74): avc:  denied  { write } for 
pid=1518 comm="cp" name="resolv.conf.predhclient.eth0" dev=dm-0 ino=196609
scontext=unconfined_u:system_r:dhcpc_t:s0
tcontext=unconfined_u:object_r:etc_t:s0 tclass=file

host=slate type=SYSCALL msg=audit(1210859214.167:74): arch=40000003 syscall=5
success=no exit=-13 a0=bfc37dc2 a1=8201 a2=0 a3=8201 items=0 ppid=1479 pid=1518
auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=1 comm="cp" exe="/bin/cp" subj=unconfined_u:system_r:dhcpc_t:s0 key=(null)


===== Copy from setroubleshoot ends

Expected results:


Additional info:

Comment 1 Daniel Walsh 2008-05-16 19:55:28 UTC
Something mislabeled this file.

restorecon /etc/resolv.conf*

will fix.

I am closing as not a bug, SELinux worked properly.  Preventing a confined
domain from writing a file labeled etc_t.  

Do you have any idea how this got mislabeled?  If you do the above command and
the problem comes back then reopen this bug and we will assign it to the package
that is mislabeling the file.  dhcp? 

Comment 2 Daniel Walsh 2008-05-16 19:56:02 UTC
*** Bug 446634 has been marked as a duplicate of this bug. ***

Comment 3 David Hislop 2008-05-18 04:43:29 UTC
/sbin/restorecon -v /etc/resolv.conf*

actually didn't display any output, but the problem seems to have gone away. I'm
fairly sure that I did

/sbin/restorecon -v /etc/resolv.conf.predhclient.eth0

before, and it didn't fix the problem. Should have taken notes ... :-(

Anyway, it happened either during or straight after installation. I booted off
the Live CD, installed to disk, rebooted off disk, enabled the network
interfaces and set them to be managed by Network Manager. I rebooted and noticed
an access error for /etc/resolv.conf.predhclient.eth0 during the boot messages
(i.e. from "Show Detail" during boot).

Sorry I don't have more specific details.

Comment 4 Daniel Walsh 2008-05-20 12:29:40 UTC
How did you "enabled the network
interfaces and set them to be managed by Network Manager"

Did you use system-config-network?

Comment 5 David Hislop 2008-05-20 12:43:30 UTC
Yes, I used system-config-network

Comment 6 Daniel Walsh 2008-05-20 19:14:57 UTC
I would bet this is the cuplrit.

Comment 7 David Hislop 2008-05-21 12:09:41 UTC
Could well be, but I think I've used it since and it hasn't done it again. 
Maybe it was a chain of events. Is there any security trace I can put on it 
while trying it again?

Comment 8 Daniel Walsh 2008-05-21 14:21:04 UTC
You could use audit to watch the file.


I think we need to look at the install of the livecd.  Check the context of
/etc/resolv.*

Run system-config-network
check context of /etc/resolv*

reboot 
check the context of /etc/resolv*

They should all be net_conf_t.



Comment 9 David Hislop 2008-05-22 14:10:59 UTC
OK, all contexts seem to be net_conf_t. I did

ls --lcontext /etc/resolv.*

and got

-rw-r--r-- 1 system_u:object_r:net_conf_t:s0  root root 244 2008-05-23 00:05
/etc/resolv.conf
-rw-r--r-- 1 system_u:object_r:net_conf_t:s0  root root  37 2008-05-15 20:02
/etc/resolv.conf.predhclient.eth0
-rw-r--r-- 1 system_u:object_r:net_conf_t:s0  root root   0 2008-05-15 07:45
/etc/resolv.conf.predhclient.eth0.moved

Booted the Live CD and got net_conf_t also.

Rebooted disk image, ran system-config-network, unchecked both wired and
wireless interfaces, edited the profiles and disabled control by NetworkManager
and turned off activate on boot, checked context again and it was net_conf_t.

Undid all the above changes and checked context again and got

-rw-r--r-- 1 system_u:object_r:net_conf_t:s0  root root 152 2008-05-23 00:06
/etc/resolv.conf
-rw-r--r-- 1 system_u:object_r:net_conf_t:s0  root root 244 2008-05-23 00:05
/etc/resolv.conf.bak
-rw-r--r-- 1 system_u:object_r:net_conf_t:s0  root root  37 2008-05-15 20:02
/etc/resolv.conf.predhclient.eth0
-rw-r--r-- 1 system_u:object_r:net_conf_t:s0  root root   0 2008-05-15 07:45
/etc/resolv.conf.predhclient.eth0.moved

Anything I missed? Should I have rebooted with the network interfaces disabled
in the middle?

Comment 10 Daniel Walsh 2008-05-24 09:32:18 UTC
No, I guess we will never know...  If it happens again we can reopen

Comment 11 David Hislop 2008-05-24 13:17:11 UTC
OK, thanks for your help, Dan



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