Bug 1006370 - The openstack-selinux policies need to be updated for the quantum -> neutron rename
The openstack-selinux policies need to be updated for the quantum -> neutron ...
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
Unspecified Linux
high Severity high
: beta
: 6.5
Assigned To: Miroslav Grepl
Michal Trunecka
Depends On: 996776
Blocks: 1013636
  Show dependency treegraph
Reported: 2013-09-10 10:03 EDT by Lon Hohberger
Modified: 2014-09-30 19:35 EDT (History)
10 users (show)

See Also:
Fixed In Version: selinux-policy-3.7.19-217.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 996776
: 1013636 (view as bug list)
Last Closed: 2013-11-21 05:51:04 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch from upstream which resolves the problem (18.92 KB, patch)
2013-09-10 10:04 EDT, Lon Hohberger
no flags Details | Diff
Untested backport (16.10 KB, patch)
2013-09-10 10:37 EDT, Lon Hohberger
no flags Details | Diff
Tested backport (17.75 KB, patch)
2013-09-18 15:45 EDT, Lon Hohberger
no flags Details | Diff

  None (edit)
Description Lon Hohberger 2013-09-10 10:03:02 EDT
+++ This bug was initially created as a clone of Bug #996776 +++

Description of problem:
Various permissions errors occur when launching neutron services/using neutron. I'm assuming that the rename from quantum to neutron broke all of the related selinux policies. All binaries, configs/dirs, usernames etc. have had s/quantum/neutron/ done.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. packstack --allinone
2. . keystonerc_demo
3. nova --boot --image cirros --flavor 1 --nic netid=${id of 'private' network} test
4. ausearch -i -m avc

Actual results:
Instance gets a DHCP address/No avc errors

Expected results:
Instance does not get a DHCP address/Lots of avc errors

Additional info:

--- Additional comment from Terry Wilson on 2013-08-19 11:04:36 EDT ---

I should also point out that neutron ships with the quantum-named binaries as well for compatibility reasons for now. So the rules should probably cover both.

--- Additional comment from lpeer on 2013-08-21 07:50:05 EDT ---

--- Additional comment from Miguel Angel Ajo on 2013-09-04 18:12:05 EDT ---

I can confirm this bug in a test environment here. (rdo-havana on CentOS 6.4)

The VMs won't receive dhcp response, 

It can be identified this way also;

# grep DHCPDISCOVER /var/log/messages

Sep  5 01:28:38 opentron dnsmasq-dhcp[3284]: DHCPDISCOVER(tapa5331882-85) fa:16:3e:96:4d:a3 no address available

# tail -f /var/log/messages | grep dnsmasq &
# killall -HUP dnsmasq

 Sep  5 01:32:05 opentron dnsmasq[2148]: read /etc/hosts - 2 addresses
Sep  5 01:32:05 opentron dnsmasq[3284]: cleared cache
Sep  5 01:32:05 opentron dnsmasq[3284]: cannot read /var/lib/neutron/dhcp/521717de-5dbe-4756-8ef2-fe17321eeae8/host: Permission denied
Sep  5 01:32:05 opentron dnsmasq-dhcp[3284]: read /var/lib/neutron/dhcp/521717de-5dbe-4756-8ef2-fe17321eeae8/host
Sep  5 01:32:05 opentron dnsmasq[3284]: cannot read /var/lib/neutron/dhcp/521717de-5dbe-4756-8ef2-fe17321eeae8/opts: Permission denied
Sep  5 01:32:05 opentron dnsmasq-dhcp[3284]: read /var/lib/neutron/dhcp/521717de-5dbe-4756-8ef2-fe17321eeae8/opts
Sep  5 01:32:05 opentron dnsmasq[2148]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
Sep  5 01:32:05 opentron dnsmasq-dhcp[2148]: read /var/lib/libvirt/dnsmasq/default.hostsfile

as a test I ran dnsmasq as root to check:
# ip net exec qdhcp-521717de-5dbe-4756-8ef2-fe17321eeae8   dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces --interface=tapa5331882-85 --except-interface=lo --pid-file=/var/lib/neutron/dhcp/521717de-5dbe-4756-8ef2-fe17321eeae8/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/521717de-5dbe-4756-8ef2-fe17321eeae8/host --dhcp-optsfile=/var/lib/neutron/dhcp/521717de-5dbe-4756-8ef2-fe17321eeae8/opts --dhcp-script=/usr/bin/neutron-dhcp-agent-dnsmasq-lease-update --leasefile-ro --dhcp-range=set:tag0,,static,120s --conf-file= --domain=openstacklocal

and it works

--- Additional comment from Lon Hohberger on 2013-09-10 09:55:01 EDT ---

This patch was rejected, but is included for reference.

--- Additional comment from Lon Hohberger on 2013-09-10 09:58:10 EDT ---
Comment 1 Lon Hohberger 2013-09-10 10:04:29 EDT
Created attachment 796020 [details]
Patch from upstream which resolves the problem
Comment 2 Lon Hohberger 2013-09-10 10:37:40 EDT
Created attachment 796034 [details]
Untested backport
Comment 4 Lon Hohberger 2013-09-10 11:21:46 EDT
Side note: we do want contexts for both Quantum and Neutron at the same time - Dan's original patch and my backport attempt to do this.
Comment 5 Lon Hohberger 2013-09-10 15:06:01 EDT
We also had this in the existing openstack-selinux policy:


Perhaps these small fixes could be merged.
Comment 6 Lon Hohberger 2013-09-18 15:45:13 EDT
Created attachment 799561 [details]
Tested backport
Comment 7 Lon Hohberger 2013-09-18 15:47:52 EDT
Test repository:

Comment 8 Lon Hohberger 2013-09-18 16:41:13 EDT
Miroslav also did a build for this; I'll update the repository with his patch/build.
Comment 9 Miroslav Grepl 2013-09-25 15:31:29 EDT
Has been already added.
Comment 13 Milos Malik 2013-10-24 06:03:30 EDT
Following 3 types were not renamed. Is it expected?

# rpm -qa selinux-policy\*
# sestatus 
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted
# for I in -t -a -r -u -b -c --portcon ; do seinfo $I | grep -i quantum ; done
	portcon tcp 9696 system_u:object_r:quantum_port_t:s0
Comment 14 Daniel Walsh 2013-10-29 11:27:53 EDT
We probably should rename them and add appropriate alias.
Comment 15 Miroslav Grepl 2013-10-29 11:32:48 EDT
Yes but I don't see as a big problem in RHEL6.5 now.
Comment 16 Daniel Walsh 2013-10-29 11:51:46 EDT

    Fix this in git.

    Miroslav we should rename the module in F20 also.
Comment 17 Michal Trunecka 2013-10-30 11:25:10 EDT
I filed the last mentioned issue as a separate Bug 1024927.
Comment 19 errata-xmlrpc 2013-11-21 05:51:04 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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