Bug 996776 - The openstack-selinux policies need to be updated for the quantum -> neutron rename
Summary: The openstack-selinux policies need to be updated for the quantum -> neutron ...
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RDO
Classification: Community
Component: openstack-selinux
Version: unspecified
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: Milestone3
: Havana
Assignee: Lon Hohberger
QA Contact: Jay Turner
URL:
Whiteboard:
Keywords: VerifiedUpstream
: 999447 1008142 (view as bug list)
Depends On:
Blocks: 1006370 1013636
TreeView+ depends on / blocked
 
Reported: 2013-08-13 22:49 UTC by Terry Wilson
Modified: 2016-04-26 18:14 UTC (History)
9 users (show)

(edit)
Clone Of:
: 1006370 (view as bug list)
(edit)
Last Closed: 2013-12-03 21:33:34 UTC


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 22:49 UTC, Terry Wilson
no flags Details
Initial patch (10.43 KB, patch)
2013-09-10 13:55 UTC, Lon Hohberger
no flags Details | Diff
Upstream patch from Dan Walsh (18.92 KB, patch)
2013-09-10 13:58 UTC, Lon Hohberger
no flags Details | Diff

Description Terry Wilson 2013-08-13 22:49:46 UTC
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 15:04:36 UTC
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 11:50:05 UTC
*** Bug 999447 has been marked as a duplicate of this bug. ***

Comment 3 Miguel Angel Ajo 2013-09-04 22:12:05 UTC
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 13:55:01 UTC
Created attachment 796015 [details]
Initial patch

This patch was rejected, but is included for reference.

Comment 5 Lon Hohberger 2013-09-10 13:58:10 UTC
Created attachment 796016 [details]
Upstream patch from Dan Walsh

Comment 6 lpeer 2013-09-16 12:49:46 UTC
*** Bug 1008142 has been marked as a duplicate of this bug. ***

Comment 7 Lon Hohberger 2013-09-18 14:39:59 UTC
Unofficial test packages:

http://people.redhat.com/lhh/selinux-policy/

Comment 8 Lon Hohberger 2013-09-18 14:42:30 UTC
This is a backport of Dan's patch:

https://bugzilla.redhat.com/attachment.cgi?id=796034

Comment 9 Sandro Mathys 2013-09-18 19:03:52 UTC
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 20:41:37 UTC
Miroslav also did a build for this; I'll update the repository with his patch/build.

Comment 11 Lon Hohberger 2013-09-19 14:08:41 UTC
I updated the packages as well.

Comment 12 Terry Wilson 2013-09-20 04:28:50 UTC
I tested the packages by setting up lhh's repo. I saw no avc denials.

Comment 13 Sandro Mathys 2013-09-20 06:43:47 UTC
(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 08:19:40 UTC
Yes, we need to be sure there is no regression.

Comment 15 Lon Hohberger 2013-09-20 14:15:25 UTC
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.