Bug 971594 - AVC denial when attaching volume to RHOS 3 instance
AVC denial when attaching volume to RHOS 3 instance
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.4
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Miroslav Grepl
Michal Trunecka
: ZStream
Depends On:
Blocks: 973776
  Show dependency treegraph
 
Reported: 2013-06-06 17:24 EDT by Eric Harney
Modified: 2014-09-30 19:35 EDT (History)
10 users (show)

See Also:
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 05:30:13 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)

  None (edit)
Description Eric Harney 2013-06-06 17:24:21 EDT
+++ 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 13:51:28 EDT
Could we get qa_ack+?
Comment 4 Miroslav Grepl 2013-06-12 06:53:03 EDT
Actually we need to add a mcs attribute.
Comment 5 Miroslav Grepl 2013-06-12 06:54:30 EDT
Fixed in selinux-policy-3.7.19-205.el6
Comment 11 errata-xmlrpc 2013-11-21 05:30:13 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.

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

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