Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 589539 - SELinux policy appears to prevent NM from interacting with avahi-autoipd correctly
Summary: SELinux policy appears to prevent NM from interacting with avahi-autoipd corr...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Ben Levenson
URL:
Whiteboard:
: 589540 589542 (view as bug list)
Depends On:
Blocks: 587845
TreeView+ depends on / blocked
 
Reported: 2010-05-06 11:59 UTC by Scott Schmit
Modified: 2010-11-03 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-03 15:38:32 UTC


Attachments (Terms of Use)
audit.log during NetworkManager IPv4 link local connection (deleted)
2010-05-08 01:01 UTC, Scott Schmit
no flags Details

Description Scott Schmit 2010-05-06 11:59:33 UTC
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.

Comment 1 Scott Schmit 2010-05-06 12:08:30 UTC
*** Bug 589540 has been marked as a duplicate of this bug. ***

Comment 2 Scott Schmit 2010-05-06 12:09:20 UTC
*** Bug 589542 has been marked as a duplicate of this bug. ***

Comment 3 Daniel Walsh 2010-05-06 13:55:26 UTC
Scott any avc messages generated in /var/log/audit/audit.log?

Comment 4 Scott Schmit 2010-05-07 00:04:41 UTC
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.

Comment 5 Daniel Walsh 2010-05-07 15:26:25 UTC
Scott,  Could you turn off dontaudit rules.

# semodule -DB
Connect in permissive mode,
Collect avc messages
# semodule -B 

to turn back on dontaudit rules.

Comment 6 Scott Schmit 2010-05-08 01:01:08 UTC
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

Comment 7 Scott Schmit 2010-05-08 01:06:49 UTC
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;

Comment 8 Daniel Walsh 2010-05-10 17:43:38 UTC
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?

Comment 9 Miroslav Grepl 2010-05-11 13:12:51 UTC
Fixed in selinux-policy-3.6.32-115.fc12

Comment 10 Bug Zapper 2010-11-03 15:30:31 UTC
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


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