Bug 608379 - SELinux is preventing /usr/bin/python "setattr" access on /var/log/wicd.log.
Summary: SELinux is preventing /usr/bin/python "setattr" access on /var/log/wicd....
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
(Show other bugs)
Version: 13
Hardware: x86_64 Linux
low
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:21f5fa0021f...
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-27 03:20 UTC by dtdraganov
Modified: 2011-05-10 06:44 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-10 06:44:45 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description dtdraganov 2010-06-27 03:20:19 UTC
Summary:

SELinux is preventing /usr/bin/python "setattr" access on /var/log/wicd.log.

Detailed Description:

SELinux denied access requested by wicd. It is not expected that this access is
required by wicd and this access may signal an intrusion attempt. It is also
possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug
report.

Additional Information:

Source Context                system_u:system_r:NetworkManager_t:s0
Target Context                system_u:object_r:var_log_t:s0
Target Objects                /var/log/wicd.log [ file ]
Source                        wicd
Source Path                   /usr/bin/python
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           python-2.6.4-27.fc13
Target RPM Packages           
Policy RPM                    selinux-policy-3.7.19-28.fc13
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     (removed)
Platform                      Linux (removed) 2.6.33.5-124.fc13.x86_64 #1 SMP Fri
                              Jun 11 09:38:12 UTC 2010 x86_64 x86_64
Alert Count                   1
First Seen                    Sun 27 Jun 2010 06:14:19 AM EEST
Last Seen                     Sun 27 Jun 2010 06:14:19 AM EEST
Local ID                      2fd32811-dee5-4826-92e8-1d87b377212c
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1277608459.477:11): avc:  denied  { setattr } for  pid=3470 comm="wicd" name="wicd.log" dev=dm-0 ino=2884841 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file

node=(removed) type=SYSCALL msg=audit(1277608459.477:11): arch=c000003e syscall=90 success=no exit=-13 a0=93e150 a1=180 a2=3dc2fb27e0 a3=7fff2bc17fd8 items=0 ppid=3469 pid=3470 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="wicd" exe="/usr/bin/python" subj=system_u:system_r:NetworkManager_t:s0 key=(null)



Hash String generated from  catchall,wicd,NetworkManager_t,var_log_t,file,setattr
audit2allow suggests:

#============= NetworkManager_t ==============
allow NetworkManager_t var_log_t:file setattr;

Comment 1 Miroslav Grepl 2010-06-28 11:00:15 UTC
execute:

restorecon -Rv /var/log/wicd

*** This bug has been marked as a duplicate of bug 608378 ***

Comment 2 Dan Christian 2010-12-14 19:19:54 UTC
I'm getting this every time.  The restorecon doesn't fix it.  wicd dies every time on startup.

# /etc/init.d/wicd start
Starting wicd service:                                     [  OK  ]
# /etc/init.d/wicd status
wicd dead but pid file exists

Starting wicd by hand works!
# wicd
# /etc/init.d/wicd status
wicd (pid  3510) is running...

I just updated to selinux-policy 3.9.7-16.fc14.
It worked (as a system started daemon) before this update (old policy may have been several weeks old).

I'm putting the comment here, because I'm not sure it's a dup any more.

I'm on Fedora 14 x86.
uname -a
Linux tesla 2.6.35.9-64.fc14.i686.PAE #1 SMP Fri Dec 3 12:28:00 UTC 2010 i686 i686 i386 GNU/Linux

Comment 3 Daniel Walsh 2010-12-14 19:54:54 UTC
After you start wicd via the service script run 

ausearch -m avc -ts recent

Comment 4 Dan Christian 2010-12-14 20:42:45 UTC
FYI: I switched selinux into permissive mode, and now the daemon stays running from boot.

I get nothing after wicd is started by hand.

Here is what I get when it is started from the script:

# ausearch -m avc -ts recent
----
time->Tue Dec 14 13:37:51 2010
type=SYSCALL msg=audit(1292359071.285:24): arch=40000003 syscall=5 success=yes exit=3 a0=9659fd0 a1=8000 a2=0 a3=0 items=0 ppid=3025 pid=3032 auid=992 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="wicd" exe="/bin/bash" subj=unconfined_u:system_r:NetworkManager_t:s0 key=(null)
type=AVC msg=audit(1292359071.285:24): avc:  denied  { open } for  pid=3032 comm="wicd" name=".shenv" dev=sda5 ino=435 scontext=unconfined_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
type=AVC msg=audit(1292359071.285:24): avc:  denied  { read } for  pid=3032 comm="wicd" name=".shenv" dev=sda5 ino=435 scontext=unconfined_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
----
time->Tue Dec 14 13:37:51 2010
type=SYSCALL msg=audit(1292359071.286:25): arch=40000003 syscall=197 success=yes exit=0 a0=3 a1=bf9a33f4 a2=31eff4 a3=3 items=0 ppid=3025 pid=3032 auid=992 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="wicd" exe="/bin/bash" subj=unconfined_u:system_r:NetworkManager_t:s0 key=(null)
type=AVC msg=audit(1292359071.286:25): avc:  denied  { getattr } for  pid=3032 comm="wicd" path="/root/.shenv" dev=sda5 ino=435 scontext=unconfined_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
----
time->Tue Dec 14 13:37:51 2010
type=SYSCALL msg=audit(1292359071.522:26): arch=40000003 syscall=5 success=yes exit=7 a0=97b7200 a1=8241 a2=1b6 a3=97b7969 items=0 ppid=1 pid=3042 auid=992 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="wicd" exe="/usr/bin/python" subj=unconfined_u:system_r:NetworkManager_t:s0 key=(null)
type=AVC msg=audit(1292359071.522:26): avc:  denied  { write } for  pid=3042 comm="wicd" name="manager-settings.conf" dev=sda5 ino=64989 scontext=unconfined_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file
----
time->Tue Dec 14 13:37:51 2010
type=SYSCALL msg=audit(1292359071.573:27): arch=40000003 syscall=15 success=yes exit=0 a0=97b6aa0 a1=180 a2=44dc0cc a3=9575050 items=0 ppid=1 pid=3042 auid=992 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="wicd" exe="/usr/bin/python" subj=unconfined_u:system_r:NetworkManager_t:s0 key=(null)
type=AVC msg=audit(1292359071.573:27): avc:  denied  { setattr } for  pid=3042 comm="wicd" name="manager-settings.conf" dev=sda5 ino=64989 scontext=unconfined_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file

Comment 5 Alexander Hunt 2010-12-15 01:32:27 UTC
Since this bug is closed, I have put some information that may be helpful under bug#608378

Comment 6 Miroslav Grepl 2010-12-15 13:25:23 UTC
Dan, 
if you execute

restorecon -R -v /etc/wicd

does it work then? 

I mean, can you start wicd via the service script in the enforcing mode?

Comment 7 Dan Christian 2010-12-15 22:20:00 UTC
I did restorecon on /etc/wicd, /var/log/wicd.log and /etc/dhcp

It removes some denials, but I still get:

SELinux is preventing /usr/bin/python "write" access on
/etc/dhcp/manager-settings.conf.

Which is this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=647030

wicd still dies when started by the script, but works if started by hand.

If it matters, I completely removed NetworkManager as per Alexander Hunt's comments.  I had to fix the context on /etc/resolve.conf after the removal (many programs were having denials).

Comment 8 Alexander Hunt 2010-12-15 23:40:25 UTC
Hi Dan Christian, 
Just so you know; I am just a regular user, albeit with a long history with wicd, so be discretionary with my advice.:) I put ideas out so people can avoid some of the problems I've had. Anyway I had a thought from your comment #7; If you haven't done so already maybe try adding yourself to the group "wheel" in (Administration/Users and Groups) and then sudo visudo in terminal and un-comments lines so they look like these:

## Allows people in group wheel to run all commands
%wheel  ALL=(ALL)       ALL

## Same thing without a password
%wheel          ALL=(ALL)       NOPASSWD:ALL

(The above is a bit of a security issue if you are on anything but your own personal home machine; use with caution)

If you're not familiar with vi, to edit you alt-i (I think, I use an apple kb, so if that doesn't work try the other keys in the area of "alt" + i

To escape once done taking out the # from in front of the above use the esc key.

To write is shift + : (colon or semi-colon; always forget which is which) then w + enter to write without quit or wq + enter to write and quit together. 

Anyway maybe try that and if wicd is not in your startup (Preferences/Startup applications) try adding it there. Mine works best if the system starts up wicd by itself.
Also manager-setting selinux contest on mine is: System configuration.
Same with resolve.conf. 
Feel free to email me or add here if you need any more info. Sorry if you know all this; I tend to err on the side of giving too much info rather than having people struggling with things.

Comment 9 Dan Christian 2010-12-16 00:15:11 UTC
I do have sudo priviledges, but I've been using "su" for all this debugging.  I find that sudo is cumbersome when you are fiddling with a bunch of stuff.  I'm not quite sure why you brought it up.  Thanks for saying too much, though.  I do the same.

I used chkconfig to enable wicd and disable NetworkManager (which has now been un-installed).

wicd is starting on boot if selinux is in permissive mode, but not in enforcing.  It will start by hand if enforcing (via su).  I can even do "daemon wicd 2> /dev/null" like the script and it works by hand (and doesn't trigger any selinux alerts).  I don't know what is different from system startup and su.

Comment 10 Alexander Hunt 2010-12-16 00:36:06 UTC
I brought it up because adding yourself to the "wheel" group makes you a part of the running system (and its privileges) instead of just a user with root privileges. The other part, allowing wheel to run any command, and then run any command without needing a password allows you to do anything the system can do without being asked for a password (for some things); Not true for anything controlled by PAM.
Anyway the problem you are having now, I had until recently as well, but now I can be in enforcing mode all the time. Check bug#659932:

Miroslav Grepl 2010-12-06 05:38:00 EST

# chcon -t NetworkManager_log_t /var/log/wicd.log 

(modified to edit context on currently running log)

Will fix.

This is where my system changed from having to be in permissive mode to working in enforcing mode.

Check bug# 608378 as well, I just added some more info there about making (hopefully) the wicd logs keep their context when they get rotated.

Comment 11 Alexander Hunt 2010-12-16 02:55:28 UTC
Dan C,
I've been working on the other issue of the logfile context changing when it's rotated and found some very interesting things.
 
1.) in this file: /usr/lib/python2.7/site-packages/wicd/wpath.py   it says:

initfile = 'init/redhat/wicd' when it is actually here: /etc/rc.d/init.d/wicd   

2.) it also says: wicd_group = 'user' - I was thinking that users aren't in the 'user' group by default, so I created a new user to check this and found I was right, and also that selinux threw the error about python not being allowed write access to /etc/dhcp/wireless-settings. Add your username to group 'user'.

3.) I found that although I am using the new selinux version, (selinux-policy 3.9.7-16.fc14), the context of  /etc/dhcp/manager-settings, wireless-settings and wired settings are not what they should be according to selinux admin app (system-config-selinux) which says they should be: NetworkManager_var_lib_t
so I did: 
sudo chcon -t NetworkManager_var_lib_t /etc/dhcp/wired-settings.conf
sudo chcon -t NetworkManager_var_lib_t /etc/dhcp/wireless-settings.conf
sudo chcon -t NetworkManager_t /etc/dhcp/manager-settings.conf

and this one if you are adding the wicd folder to /var/log/
(as per info in bug# 608378 )
sudo chcon -t NetworkManager_log_t /var/log/wicd/

After fixing the above, doing a shutdown and startup, selinux is not throwing any errors in the new user account I made for testing.
I hope that helps.

Comment 12 Alexander Hunt 2010-12-18 04:27:52 UTC
Hi all, I've just had this issue come up again after I just updated to selinux 3.9.7-18.fc14 from the updates-testing repo, doing a boot-time relabel and starting up again.

/var/log/wicd had context reset as 'logfile' after update and relabel.
/var/log/wicd/wicd.log had context reset as 'logfile' after update and relabel.

wicd did not start with selinux call:
/usr/bin/python: attempted this access: setattr on: var/log/wicd/wicd.log

I again used:
sudo chcon -t NetworkManager_log_t /var/log/wicd
sudo chcon -t NetworkManager_log_t /var/log/wicd/wicd.log

to change context back.

Then exited Wicd Manager (GTK icon).
Then restarted wicd network manager (GTK icon) from menu (or at commandline : wicd-gtk)
Wicd connected immediately.

Daniel, in system-config-selinux / "file labelling" I created a new file specification for /var/log/wicd/wicd.* with filetype: NetworkManager_log_t:s0 and regular file, and another the same except for the new wicd directory labelled as a directory. My question is will these stay in there when the selinux policy updates come out, or are they all replaced on each update? 
Thanks again, as always, for all your help. a.

Comment 13 Miroslav Grepl 2011-03-09 16:02:23 UTC
Let's clean up this bug. 

Does this still happen on F13, F14?

If so,
please open a new bug for F14 or add the comment here for F13.


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