Bug 497278

Summary: SELinux is preventing nm-system-setti (NetworkManager_t) "write" to ifcfg-eth0 (etc_t).
Product: [Fedora] Fedora Reporter: Matěj Cepl <mcepl>
Component: system-config-networkAssignee: Harald Hoyer <harald>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: dcbw, dwalsh, harald, jmoskovc, mcepl, mefoster
Target Milestone: ---Keywords: SELinux
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-27 12:58:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matěj Cepl 2009-04-23 07:18:27 UTC
Souhrn:

SELinux is preventing nm-system-setti (NetworkManager_t) "write" to ifcfg-eth0
(etc_t).

Podrobný popis:

SELinux is preventing nm-system-setti (NetworkManager_t) "write" to ifcfg-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 (ifcfg-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
'ifcfg-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.

Povolení přístupu:

You can attempt to fix file context by executing restorecon -v 'ifcfg-eth0'

Příkaz pro opravu:

restorecon 'ifcfg-eth0'

Další informace:

Kontext zdroje                system_u:system_r:NetworkManager_t:s0-s0:c0.c1023
Kontext cíle                 system_u:object_r:etc_t:s0
Objekty cíle                 ifcfg-eth0 [ file ]
Zdroj                         nm-system-setti
Cesta zdroje                  /usr/sbin/nm-system-settings
Port                          <Neznámé>
Počítač                    viklef.ceplovi.cz
RPM balíčky zdroje          NetworkManager-0.7.1-3.git20090414.fc11
RPM balíčky cíle           
RPM politiky                  selinux-policy-3.6.12-9.fc11
Selinux povolen               True
Typ politiky                  targeted
MLS povoleno                  True
Vynucovací režim            Enforcing
Název zásuvného modulu     mislabeled_file
Název počítače            viklef.ceplovi.cz
Platforma                     Linux viklef.ceplovi.cz 2.6.29.1-102.fc11.x86_64
                              #1 SMP Mon Apr 20 15:33:38 EDT 2009 x86_64 x86_64
Počet upozornění           1
Poprvé viděno               Čt 23. duben 2009, 09:14:16 CEST
Naposledy viděno             Čt 23. duben 2009, 09:14:16 CEST
Místní ID                   4b43077a-2e2d-4ea4-bf0e-fd2742884801
Čísla řádků              

Původní zprávy auditu      

node=viklef.ceplovi.cz type=AVC msg=audit(1240470856.64:31): avc:  denied  { write } for  pid=1936 comm="nm-system-setti" name="ifcfg-eth0" dev=dm-0 ino=196236 scontext=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file

node=viklef.ceplovi.cz type=SYSCALL msg=audit(1240470856.64:31): arch=c000003e syscall=2 success=no exit=-13 a0=17f3390 a1=41 a2=1a4 a3=1 items=0 ppid=1 pid=1936 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nm-system-setti" exe="/usr/sbin/nm-system-settings" subj=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 key=(null)

Comment 1 Matěj Cepl 2009-04-23 07:19:55 UTC
Happened just by changing network settings via system-config-network run as root (I am staff_u, so s-c-n doesn't work for me as normal user).

Comment 2 Daniel Walsh 2009-04-23 12:26:42 UTC
system-config-netowork should be setting the correct context on the files it is editing.

The directory is labeled net_conf_t, so system-config-network must be editing the files in a separate directory and moving them here.  

system-config-network could just 
import selinux; restorecon PATH

Which would set the correct context on the file, or just create it in the /etc/syscoinfig/network-scripts directory.

Comment 3 Harald Hoyer 2009-04-23 13:24:36 UTC
The files are created in the /etc/sysconfig/networking directory and hardlinked from the actual profile to /etc/sysconfig/network-scripts.

Yes, I will add restorecon.

Comment 4 Daniel Walsh 2009-04-23 14:44:34 UTC
Wait Harald, The correct solution then it to make sure the /etc/sysconfig/profiles directory is labeled 

net_conf_t and then everything will just work.

/etc/sysconfig/networking/profiles(/.*)? gen_context(system_u:object_r:net_conf_t,s0)


If you execute 

chcon -R -t net_conf_t /etc/sysconfig/networking/profiles

Then run system-config-network everything should work.

Fixed in selinux-policy-3.6.12-14.fc11.noarch

Comment 5 Daniel Walsh 2009-04-23 14:46:21 UTC
Actually should be at

/etc/sysconfig/networking(/.*)? gen_context(system_u:object_r:net_conf_t,s0)

Comment 6 Niels Haase 2009-04-23 20:05:52 UTC
*** Bug 496246 has been marked as a duplicate of this bug. ***

Comment 7 Mary Ellen Foster 2009-04-27 09:30:12 UTC
I just tried the chcon comment in comment #5 and the problem I reported in bug 496246 no longer occurs.