Bug 1139662 - boxes cannot start machine
Summary: boxes cannot start machine
Keywords:
Status: CLOSED DUPLICATE of bug 1141879
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-09 11:49 UTC by Vladimir Benes
Modified: 2014-09-18 12:43 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-18 12:43:38 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Vladimir Benes 2014-09-09 11:49:06 UTC
Description of problem:
after upgrading to latest libvirt (1.2.8-1) I cannot create box (or connect to it) I see this log in audit.log

http://fpaste.org/132065/41026318/

Version-Release number of selected component (if applicable):
boxes-3.13.91-1
libvirt-1.2.8-1
selinux-policy-3.13.1-78.fc21.noarch

How reproducible:
always

Steps to Reproduce:
1.open boxes
2.create new box 

Actual results:
failed to start VM

Expected results:
vm should be started correctly

Additional info:
setenforce=0 helps

Comment 1 Miroslav Grepl 2014-09-09 13:49:18 UTC
Could you try it with

#semodule -B
re-test and
#ausearch -m avc,user_avc -ts recent

Comment 2 Vladimir Benes 2014-09-11 12:09:25 UTC
SELinux is preventing qemu-system-x86 from ioctl access on the chr_file /dev/net/tun.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that qemu-system-x86 should be allowed ioctl access on the tun chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep qemu-system-x86 /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:svirt_t:s0:c393,c538
Target Context                system_u:object_r:svirt_image_t:s0:c295,c359
Target Objects                /dev/net/tun [ chr_file ]
Source                        qemu-system-x86
Source Path                   qemu-system-x86
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-79.fc21.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain 3.16.1-301.fc21.x86_64
                              #1 SMP Mon Aug 25 13:06:39 UTC 2014 x86_64 x86_64
Alert Count                   1
First Seen                    2014-09-11 08:06:10 EDT
Last Seen                     2014-09-11 08:06:10 EDT
Local ID                      ec18c60c-bcf2-49c8-a4fb-91ff660bdc29

Raw Audit Messages
type=AVC msg=audit(1410437170.925:604): avc:  denied  { ioctl } for  pid=22476 comm="qemu-system-x86" path="/dev/net/tun" dev="devtmpfs" ino=12606 scontext=unconfined_u:unconfined_r:svirt_t:s0:c393,c538 tcontext=system_u:object_r:svirt_image_t:s0:c295,c359 tclass=chr_file permissive=1


Hash: qemu-system-x86,svirt_t,svirt_image_t,chr_file,ioctl

Comment 3 Miroslav Grepl 2014-09-11 14:18:37 UTC
Yes, we know about this issue. It is caused by libvirtd fixes. We probably will need to allow virtd_t to access tun_socket for svirt_t for F21 until we get a libvirt solution.

Comment 4 Branko Grubić 2014-09-18 09:50:21 UTC
I also have issues starting VM in boxes on f21, not sure how to check is it the same issue? 

When I 'setenforce 0' it "works" starts VM, but I think there are other boxes issues.

Sep 18 11:09:32 localhost.localdomain libvirtd[7922]: Unable to open vhost-net. Opened so far 0, requested 1
Sep 18 11:09:32 localhost.localdomain libvirtd[7922]: unable to set security context 'unconfined_u:object_r:svirt_image_t:s0:c535,c824' on fd 21: Operation not permitted
Sep 18 11:09:32 localhost.localdomain gnome-boxes.desktop[7907]: (gnome-boxes:7907): Boxes-WARNING **: machine.vala:573: Failed to start Fedora: Unable to start domain: unable to set security context 'unconfined_u:object_r:svirt_image_t:s0:c535,c824' on fd 21: Operation not permitted

Comment 5 Cole Robinson 2014-09-18 12:43:38 UTC

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


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