Bug 608378 - SELinux is preventing /usr/bin/python "signal" access .
Summary: SELinux is preventing /usr/bin/python "signal" access .
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 13
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:a396b1b8901...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-27 03:19 UTC by dtdraganov
Modified: 2011-05-25 20:23 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-05-25 20:23:16 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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

SELinux is preventing /usr/bin/python "signal" access .

Detailed Description:

[wicd has a permissive type (NetworkManager_t). This access was not denied.]

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                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Target Objects                None [ process ]
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                    Sat 26 Jun 2010 05:38:31 PM EEST
Last Seen                     Sat 26 Jun 2010 05:38:31 PM EEST
Local ID                      b158909d-2127-4d17-9ddd-820f475e59aa
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1277563111.117:68212): avc:  denied  { signal } for  pid=7769 comm="wicd" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process

node=(removed) type=SYSCALL msg=audit(1277563111.117:68212): arch=c000003e syscall=62 success=yes exit=4294967424 a0=165a a1=f a2=1 a3=7fffa40a9418 items=0 ppid=7768 pid=7769 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,unconfined_t,process,signal
audit2allow suggests:

#============= NetworkManager_t ==============
allow NetworkManager_t unconfined_t:process signal;

Comment 1 Miroslav Grepl 2010-06-28 10:59:13 UTC
How did you start wicd? Did you start it directly?

What is your output of the following command

# ps -eZ | grep wicd

Comment 2 Miroslav Grepl 2010-06-28 11:00:15 UTC
*** Bug 608379 has been marked as a duplicate of this bug. ***

Comment 3 Fedora Admin XMLRPC Client 2010-11-08 21:49:36 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Fedora Admin XMLRPC Client 2010-11-08 21:50:08 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 5 Fedora Admin XMLRPC Client 2010-11-08 21:51:21 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 6 Alexander Hunt 2010-12-15 02:00:00 UTC
Hi all, I just have some thoughts about all the problems with wicd, so here goes:

First thing for anyone new to wicd to know: You cannot have Network Manager and Wicd running at the same time (Administration/Services). If you want to use wicd, disable network manager entirely. FYI, I totally un-installed all network manager programs and config files, and have had no issues resulting from doing that.

Next: Dan and Miroslav have been going way beyond the call of duty trying to resolve the issues with wicd; for that I thank you both, but I think some changes to the wicd program code are in order. I wish network manager would keep a notebook computer connected to the network, but it doesn't and beyond that does not reconnect when it does lose the connection. Wicd (in my experience) keeps the computer connected to the network 99.9% of the time, and always reconnects on a loss. Anyway my point here is that it is worth fixing the issues. 
I believe in one of the bugs since F14 came out, Dan or Miroslav said that the files in a folder will inherit the selinux context from the folders context. If that is true, then /etc/wicd/ should hold all of the config files for wicd, and it should be made to not look at /etc/dhcp or any other folder in /etc. Further to this, /var/log/ should have a wicd folder in it so that the log files can get the correct selinux context from the wicd folder. 
I believe that the only problem I have remaining is that every time the log is changed, a selinux warning is thrown. To resolve this issue for the time being, I have cron running: sudo restorecon /var/log/wicd.log every 30 minutes because I cannot find any rhyme or reason to when the log is rotated. It doesn't seem to be based on file size or a discernible time-frame. For me, this cron job has stopped any wicd/selinux errors, selinux related disconnects, or failures to connect on start-up. (FYI it connects on it's own at startup)
The other thing that has helped is setting the IP address, netmask and DNS info into wicd's GTK ui so that wicd isn't reading from /dhcp/manager-settings.conf ,but has it's own info to start up from. 
Anyway, I guess my point here is if someone can get the people who look after wicd working together with Dan and Miroslav, the issues may be resolved a lot more quickly. If there is anything anyone wants for information or help from me, don't hesitate to ask, I have lots of free time to work on this. Sorry for writing a book.:)
Happy Holidays to all!

Comment 7 Daniel Walsh 2010-12-15 15:32:53 UTC
If the log file moved to /var/log/wicd/wicd.log it would also solve your problem.

Comment 8 Alexander Hunt 2010-12-15 18:48:35 UTC
Yes, that's what I was thinking given that I'm sure I read in one of the other wicd bugs for F14 that files inherit selinux context from the parent folder. 
The problem with wicd for me is that it does not have a .conf file to easily make changes to wicd's behavior, and is written in python which I have a difficult time trying to figure out what it is doing (I'm not a programmer, but do have limited experience doing programming). I have been going through all of wicd's python files this morning trying to figure out which one controls the log files.:) Anyway, as I said, if there is anything I can do for you or Miroslav to help, just let me know. Thanks very much for all of your work on these wicd issues Dan.:)

Comment 9 Alexander Hunt 2010-12-16 00:20:16 UTC
Well I found the file with all the path variables. It is:

/usr/lib/python2.7/site-packages/wicd/wpath.py

I changed the logfile variable in that file to /var/log/wicd/

I created the folder /var/log/wicd
 
I set the owner as root and group as wheel, used:

chcon -t NetworkManager_log_t /var/log/wicd

copied the most recent wicd.log to the new folder 

and chcon -t NetworkManager_log_t /var/log/wicd/wicd.log
(prob not necessary)

Shutdown and started back up. It worked, nothing in the logs or anything from selinux, so now to see if the file keeps it's context when it gets rotated. I'm going to set that as a cron job and see what happens asap. Right now have to go work on Christmas decorations...lol :)

Comment 10 Miroslav Grepl 2011-05-25 20:23:16 UTC
Should be fixed in the latest release. If the problem still exists, please reopen the bug.

Thank you.


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