Bug 1369884

Summary: selinux prevents KVM VMs from starting.
Product: [Fedora] Fedora Reporter: Dawid Zamirski <dzrudy>
Component: selinux-policy-targetedAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED DUPLICATE QA Contact: Ben Levenson <benl>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 24CC: dwalsh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-24 17:45:14 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:
Attachments:
Description Flags
audit.log none

Description Dawid Zamirski 2016-08-24 15:30:01 UTC
Created attachment 1193676 [details]
audit.log

Description of problem:
KVM Virtual Machines fail to start with SELinux access denied error, both from CLI and Virt-Manager (even under root account)

virsh # start Windows7_Siris
error: Failed to start domain Windows7_Siris
error: SELinux policy denies access.

This started happening after installing recent updates on Fedora 24. The only 'unusual' thing on the system is that disk images for the VMs are stored in user's home dir with the following permissions and SELinux context:

-rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 137067102208 Aug 23 17:25 Windows7_Siris.qcow2


Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.13.1-191.12.fc24.noarch

How reproducible:
Always

Steps to Reproduce:
virsh # start Windows7_Siris
error: Failed to start domain Windows7_Siris
error: SELinux policy denies access.

Actual results:
VM failed to start due to SELinux policy.

Expected results:
Should start just fine as it used to.

Additional info:
attached audit.log

Comment 1 Dawid Zamirski 2016-08-24 15:33:15 UTC
PS. audit2allow claims 'Nothing to do' given attached audit.log. So the only option I was left with was to setenforce 0 temporarily.

Comment 2 Daniel Walsh 2016-08-24 17:45:14 UTC

*** This bug has been marked as a duplicate of bug 1368745 ***