Bug 996776 - 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 ...
Status: CLOSED CURRENTRELEASE
Product: RDO
Classification: Community
Component: openstack-selinux (Show other bugs)
unspecified
Unspecified Unspecified
urgent Severity urgent
: Milestone3
: Havana
Assigned To: Lon Hohberger
Jay Turner
: VerifiedUpstream
: 999447 1008142 (view as bug list)
Depends On:
Blocks: 1006370 1013636
  Show dependency treegraph
 
Reported: 2013-08-13 18:49 EDT by Terry Wilson
Modified: 2016-04-26 14:14 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1006370 (view as bug list)
Environment:
Last Closed: 2013-12-03 16:33:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of ausearch -i -m avc after doing packstack --allinone and launching a VM (8.37 KB, text/plain)
2013-08-13 18:49 EDT, Terry Wilson
no flags Details
Initial patch (10.43 KB, patch)
2013-09-10 09:55 EDT, Lon Hohberger
no flags Details | Diff
Upstream patch from Dan Walsh (18.92 KB, patch)
2013-09-10 09:58 EDT, Lon Hohberger
no flags Details | Diff

  None (edit)
Description Terry Wilson 2013-08-13 18:49:46 EDT
Created attachment 786326 [details]
output of ausearch -i -m avc after doing packstack --allinone and launching a VM

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:
Always

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:
Comment 1 Terry Wilson 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.
Comment 2 lpeer 2013-08-21 07:50:05 EDT
*** Bug 999447 has been marked as a duplicate of this bug. ***
Comment 3 Miguel Angel Ajo 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,10.0.0.0,static,120s --conf-file= --domain=openstacklocal

and it works
Comment 4 Lon Hohberger 2013-09-10 09:55:01 EDT
Created attachment 796015 [details]
Initial patch

This patch was rejected, but is included for reference.
Comment 5 Lon Hohberger 2013-09-10 09:58:10 EDT
Created attachment 796016 [details]
Upstream patch from Dan Walsh
Comment 6 lpeer 2013-09-16 08:49:46 EDT
*** Bug 1008142 has been marked as a duplicate of this bug. ***
Comment 7 Lon Hohberger 2013-09-18 10:39:59 EDT
Unofficial test packages:

http://people.redhat.com/lhh/selinux-policy/
Comment 8 Lon Hohberger 2013-09-18 10:42:30 EDT
This is a backport of Dan's patch:

https://bugzilla.redhat.com/attachment.cgi?id=796034
Comment 9 Sandro Mathys 2013-09-18 15:03:52 EDT
Patch looks good to me after a (very) quick test. Obviously it's hard to test each and every aspect of Neutron but at least the access denied message as described in comment #3 have vanished, dnsmasq was able to read those files just fine - and I never noticed any other SELinux-related issues anyway, myself.
Comment 10 Lon Hohberger 2013-09-18 16:41:37 EDT
Miroslav also did a build for this; I'll update the repository with his patch/build.
Comment 11 Lon Hohberger 2013-09-19 10:08:41 EDT
I updated the packages as well.
Comment 12 Terry Wilson 2013-09-20 00:28:50 EDT
I tested the packages by setting up lhh's repo. I saw no avc denials.
Comment 13 Sandro Mathys 2013-09-20 02:43:47 EDT
(In reply to Terry Wilson from comment #12)
> I tested the packages by setting up lhh's repo. I saw no avc denials.

FWIW: the issue in this bug never created any AVC denials but just stopped things from working.

Anyway, also tested the updated packages and all looks good.
Comment 14 Miroslav Grepl 2013-09-20 04:19:40 EDT
Yes, we need to be sure there is no regression.
Comment 15 Lon Hohberger 2013-09-20 10:15:25 EDT
Ok, so we need to see if RDO/Grizzly still works

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