Bug 971594

Summary: AVC denial when attaching volume to RHOS 3 instance
Product: Red Hat Enterprise Linux 6 Reporter: Eric Harney <eharney>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Michal Trunecka <mtruneck>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 6.4CC: apevec, dwalsh, ebenes, eharney, kchamart, ksrot, lhh, mgrepl, mmalik, mtruneck
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-3.7.19-205.el6 Doc Type: Bug Fix
Doc Text:
Previously, SELinux returned AVC denial messages during attempts to attach an LVM volume to a Red Hat OpenStack 3 instance. The relevant SELinux policy rules have been modified to add an additional MCS attribute for hald_t SELinux domain, and AVC denial messages are no longer returned when attaching LVM volume to a Red Hat OpenStack 3 instance.
 Story Points: ---
Clone Of: 965311 Environment:
Last Closed: 2013-11-21 10:30:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 973776    

Description Eric Harney 2013-06-06 21:24:21 UTC 
+++ This bug was initially created as a clone of Bug #965311 +++

Description of problem:
SSIA

[root@localhost ~]# grep AVC /var/log/audit/audit.log 
type=AVC msg=audit(1369085100.398:307633): avc:  denied  { read } for  pid=9144 comm="hald-probe-stor" path="/dev/sda" dev=devtmpfs ino=147635 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:svirt_image_t:s0:c388,c537 tclass=blk_file

Version-Release number of selected component (if applicable): 
openstack-selinux-0.1.2-10.el6ost.noarch

How reproducible: Unknown; was not able to reproduce

Steps to Reproduce:
1. Fresh install
2. Create instance
3. Create volume
4. Attach instance to volume

Actual results: AVC denial

I will have to reproduce this and have specific steps.

--- Additional comment from Kashyap Chamarthy on 2013-06-06 16:06:58 EDT ---

Possible test reproducer for attaching a volume to an instance:

------------------------------------------------
	# Create a cinder volume, and list it
	$ cinder create --display_name=bootable_volume 1
	$ cinder list

	# Add the cinder volume to env. This is the output of "cinder list"
	$ VOLUME_ID=2c370395-7f59-4c89-b312-ba35dbb986c0
	$ echo $VOLUME_ID

	# boot an instance
	$ nova boot --image e1b71961-d66d-4315-8e83-32aa1bd44f3f --flavor 1 --key_name oskey
f17-builder

	# Ensure the above booted instance is ACTIVE
	$ nova list | grep f17-builder
	$ cinder list
	
	# Attach a volume
	$ nova volume-attach f17-builder 2c370395-7f59-4c89-b312-ba35dbb986c0 /dev/vdb
	$ cinder list
	$ ssh -i oskey.priv 192.168.32.4
------------------------------------------------

--- Additional comment from Eric Harney on 2013-06-06 16:08:36 EDT ---

I reproduced this (the logged AVCs) by following the same steps as above: install, boot vm, attach an LVM iSCSI Cinder volume.

But, it doesn't seem to break anything, and the attach works.

Unclear what is accessing /dev/sda, maybe something triggered by iscsiadm.

Same openstack-selinux ver, openstack-nova-* 2013.1.1-3.

--- Additional comment from Eric Harney on 2013-06-06 16:17:21 EDT ---

Note: /dev/sda is the device node for the disk created when the iSCSI initiator logs in during volume attach.

--- Additional comment from Daniel Walsh on 2013-06-06 17:00:28 EDT ---

This would be a general bug in policy and would happen with or without openstack, it should be fixed.
Comment 2 Miroslav Grepl 2013-06-10 17:51:28 UTC 
Could we get qa_ack+?
Comment 4 Miroslav Grepl 2013-06-12 10:53:03 UTC 
Actually we need to add a mcs attribute.
Comment 5 Miroslav Grepl 2013-06-12 10:54:30 UTC 
Fixed in selinux-policy-3.7.19-205.el6
Comment 11 errata-xmlrpc 2013-11-21 10:30:13 UTC 
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.

http://rhn.redhat.com/errata/RHBA-2013-1598.html