Bug 996776

Summary: The openstack-selinux policies need to be updated for the quantum -> neutron rename
Product: [Community] RDO Reporter: Terry Wilson <twilson>
Component: openstack-selinuxAssignee: Lon Hohberger <lhh>
Status: CLOSED CURRENTRELEASE QA Contact: Jay Turner <jkt>
Severity: urgent Docs Contact:
Priority: urgent    
Version: unspecifiedCC: bsettle, dwalsh, mangelajo, mgrepl, mtruneck, oblaut, parsonsa, sandro, srevivo
Target Milestone: Milestone3Keywords: VerifiedUpstream
Target Release: Havana   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1006370 (view as bug list) Environment:
Last Closed: 2013-12-03 21:33:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 1006370, 1013636    
Attachments:
Description Flags
output of ausearch -i -m avc after doing packstack --allinone and launching a VM
none
Initial patch
none
Upstream patch from Dan Walsh none

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