Bug 1146529

What AVCs do you see?

# ausearch -m avc -m user_avc -m selinux_err -i -ts today

Adding a needinfo on me for providing info requested on comment #2. I'll provide as soon as I can.

Created attachment 942310 [details]
ausearch output

ausearch -m avc -m user_avc -m selinux_err -i -ts 25/09/2014 >ausearch.txt

Not sure if related, but seems that the workaround pushed for fixing bug #1127460 resolves the selinux issues.

type=AVC msg=audit(25/09/2014 07:56:32.083:1678) : avc:  denied  { write } for  pid=6963 comm=qemu-kvm path=/dev/dm-9 dev="devtmpfs" ino=66167 scontext=system_u:system_r:svirt_t:s0:c149,c360 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file


this one is libvirt bug.


type=AVC msg=audit(25/09/2014 08:06:37.998:2573) : avc:  denied  { read } for  pid=25512 comm=ping path=/dev/dm-8 dev="devtmpfs" ino=130548 scontext=system_u:system_r:ping_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file

this is a leak. 

I added

commit 55a14f3158ce1a59b4b25c4dbbf6795ed6cf211d
Author: Miroslav Grepl <mgrepl>
Date:   Mon Oct 6 14:54:57 2014 +0200

    ALlow sanlock_t to read sysfs_t.

*** Bug 1150427 has been marked as a duplicate of this bug. ***

I tried to setup hosted-engine on RHEL7 with selinux-policy-3.13.1-4 but it's still blocked by selinux.

 time->Wed Oct 15 10:02:37 2014
 type=SYSCALL msg=audit(1413360157.163:3312): arch=c000003e syscall=2 success=no exit=-13 a0=7f2a48966410 a1=105002 a2=0 a3=1 items=0 ppid=1 pid=5195 auid=4294967295 uid=179 gid=179 euid=179 suid=179 fsuid=179 egid=179 sgid=179 fsgid=179 tty=(none) ses=4294967295 comm="sanlock" exe="/usr/sbin/sanlock" subj=system_u:system_r:sanlock_t:s0-s0:c0.c1023 key=(null)
 type=AVC msg=audit(1413360157.163:3312): avc:  denied  { read write } for  pid=5195 comm="sanlock" name="dm-9" dev="devtmpfs" ino=611495 scontext=system_u:system_r:sanlock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:svirt_image_t:s0 tclass=blk_file

I'm not really sure it's a selinux-policy issue or a labeling problem from vdsm.
 [root@r70st1 ~]# ls -lZ /dev/dm-9 
 brw-rw----. vdsm qemu system_u:object_r:svirt_image_t:s0 /dev/dm-9

(In reply to Miroslav Grepl from comment #6)
> type=AVC msg=audit(25/09/2014 07:56:32.083:1678) : avc:  denied  { write }
> for  pid=6963 comm=qemu-kvm path=/dev/dm-9 dev="devtmpfs" ino=66167
> scontext=system_u:system_r:svirt_t:s0:c149,c360
> tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file
> 
> 
> this one is libvirt bug.

This looks like vdsm image that lost the libvirt selinux label - bug 1127460. This should be fixed in latest ovirt 3.5.

(In reply to Nir Soffer from comment #10)
> (In reply to Miroslav Grepl from comment #6)
> > type=AVC msg=audit(25/09/2014 07:56:32.083:1678) : avc:  denied  { write }
> > for  pid=6963 comm=qemu-kvm path=/dev/dm-9 dev="devtmpfs" ino=66167
> > scontext=system_u:system_r:svirt_t:s0:c149,c360
> > tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file
> > 
> > 
> > this one is libvirt bug.
> 
> This looks like vdsm image that lost the libvirt selinux label - bug
> 1127460. This should be fixed in latest ovirt 3.5.

I runned it again updating to vdsm-4.16.7-1.el7 from a yesterday build and now vdsm it's able to start the VM over iscsi with sanlock.

Works for me on these components:
rhevm-guest-agent-common-1.0.10-2.el6ev.noarch
rhevm-3.5.0-0.28.el6ev.noarch
ovirt-hosted-engine-ha-1.2.4-5.el7ev.noarch
sanlock-3.1.0-2.el7.x86_64
vdsm-4.16.8.1-5.el7ev.x86_64
ovirt-hosted-engine-setup-1.2.1-8.el7ev.noarch
qemu-kvm-rhev-1.5.3-60.el7_0.11.x86_64
ovirt-host-deploy-1.3.0-2.el7ev.noarch
libvirt-client-1.1.1-29.el7_0.4.x86_64
Linux version 3.10.0-123.19.1.el7.x86_64 (mockbuild.eng.bos.redhat.com) (gcc version 4.8.2 20140120 (Red Hat 4.8.2-16) (GCC) ) #1 SMP Mon Dec 15 14:04:04 EST 2014-on 3 hosts

Linux version 2.6.32-504.3.3.el6.x86_64 (mockbuild.eng.bos.redhat.com) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-9) (GCC) ) #1 SMP Fri Dec 12 16:05:43 EST 2014-on HE VM.


I installed HE over iSCSI LUN of 35Gig from first host running on RHEL7.0 and then added 2 more RHEL7.0 hosts to the HE setup, while using answer file from first host. All hosts became operational via WEBUI and all were deployed using iSCSI for HE VM creation and also another LUN on the same storage was used at separate LUN for guest-VM disks, all worked flawlessly.

Selinux was enforcing on all three hosts.

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.

https://rhn.redhat.com/errata/RHBA-2015-0458.html