Description of problem: See Bug 587845. When run as root from the commandline, NM is able to establish a link-local connection on IPv4 by using avahi-autoipd. When run as a service, it cannot. The only time that setroubleshooter yells at me is when I run NM from the commandline (because it screws up the context for /etc/resolv.conf and /var/run/nm-dhclient-wlan0.conf) so I'm guessing there's some dontaudits covering up the issue. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.6.32-113.fc12.noarch NetworkManager-0.8.0-12.git20100504.fc12.x86_64 (not sure that this is relevant) How reproducible: 100% Steps to Reproduce: 1. Create a connection in NetworkManager with an IPv4 method of "Link-Local" 2. Attempt to connect to that connection Actual results: From the logs, you can see that NM calls to avahi-autoipd and then times out. Run from the commandline, it does not time out, it works. Expected results: It should not time out. Additional info: NetworkManager executes "avahi-autoipd --script /usr/libexec/nm-avahi-autoipd.action <interface>". $ ls -lZ /usr/libexec/nm-avahi-autoipd.action /usr/sbin/avahi-autoipd /usr/sbin/NetworkManager -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/libexec/nm-avahi-autoipd.action -rwxr-xr-x. root root system_u:object_r:avahi_exec_t:s0 /usr/sbin/avahi-autoipd -rwxr-xr-x. root root system_u:object_r:NetworkManager_exec_t:s0 /usr/sbin/NetworkManager From that, I'm guessing that avahi_t isn't being allowed to do whatever it's supposed to do to let NetworkManager_t know it succeeded.
*** Bug 589540 has been marked as a duplicate of this bug. ***
*** Bug 589542 has been marked as a duplicate of this bug. ***
Scott any avc messages generated in /var/log/audit/audit.log?
No. I did a tail -f on the log while I attempted the connection, and nothing was added to the log, which would explain why setroubleshoot didn't complain either. That's why I suggested that there may be a dontaudit blocking any reporting. By the way (in case you didn't see it on the other bug), Dan Williams says: ------ NM executes avahi-autoipd. avahi-autoipd then chroots, drops privileges to the 'avahi' user & group, and then executes /usr/libexec/nm-avahi-autoipd.action which sends the configuration back to NM via D-Bus. ------ And I can also confirm that when I run setenforce 0 before trying the connection, the connection succeeds.
Scott, Could you turn off dontaudit rules. # semodule -DB Connect in permissive mode, Collect avc messages # semodule -B to turn back on dontaudit rules.
Created attachment 412469 [details] audit.log during NetworkManager IPv4 link local connection These are the commands I executed during this snippet, to give some context: # semodule -DB # tail -f /var/log/audit/audit.log > log-today & <attempt to connect -- failed> # setenforce 0 <attempt to connect -- succeeded> # setenforce 1 # semodule -B
Hrm... running audit2allow, if I had to take a wild guess, I'd say that the missing rule is: allow avahi_t NetworkManager_t:dbus send_msg;
That would make the most sence You can add this allow rule using # grep avahi /var/log/audit.log | audit2allow -M myavahi # semodule -i myavahi.pp Miroslav can you add this?
Fixed in selinux-policy-3.6.32-115.fc12
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping