Bug 862335

Summary: non-kvm qemu guests fail to start due to execmem: libvirt needs to label with svirt_nokvm_t
Product: [Fedora] Fedora Reporter: Christophe Fergeau <cfergeau>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: berrange, clalancette, crobinso, dominick.grift, dwalsh, eischmann, fran, itamar, jforbes, jyang, laine, libvirt-maint, mgrepl, veillard, virt-maint
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Unspecified   
Whiteboard: abrt_hash:9d2cc420dc38d7438434c2480a2fe20533d39b059c9d0bddc1cd7143a9f17d7d
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-12-12 09:59:14 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
File: type
none
File: hashmarkername none

Description Christophe Fergeau 2012-10-02 12:45:14 EDT
Description of problem:
I tried to start a VM from gnome-boxes running in a VM. No nested kvm so it started it emulating the CPU, and this gave this error

Additional info:
libreport version: 2.0.14
kernel:         3.6.0-0.rc6.git0.2.fc18.i686.PAE

description:
:SELinux is preventing qemu-system-i38 from using the 'execmem' accesses on a process.
:
:*****  Plugin catchall (100. confidence) suggests  ***************************
:
:If you believe that qemu-system-i38 should be allowed execmem access on processes labeled svirt_t 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-i38 /var/log/audit/audit.log | audit2allow -M mypol
:# semodule -i mypol.pp
:
:Additional Information:
:Source Context                unconfined_u:unconfined_r:svirt_t:s0:c68,c970
:Target Context                unconfined_u:unconfined_r:svirt_t:s0:c68,c970
:Target Objects                 [ process ]
:Source                        qemu-system-i38
:Source Path                   qemu-system-i38
:Port                          <Unknown>
:Host                          (removed)
:Source RPM Packages           
:Target RPM Packages           
:Policy RPM                    selinux-policy-3.11.1-25.fc18.noarch
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Enforcing
:Host Name                     (removed)
:Platform                      Linux (removed) 3.6.0-0.rc6.git0.2.fc18.i686.PAE
:                              #1 SMP Mon Sep 17 17:28:04 UTC 2012 i686 i686
:Alert Count                   1
:First Seen                    2012-10-02 16:35:06 CEST
:Last Seen                     2012-10-02 16:35:06 CEST
:Local ID                      5842b06c-cdae-4d3a-9673-40187dcb9565
:
:Raw Audit Messages
:type=AVC msg=audit(1349188506.231:407): avc:  denied  { execmem } for  pid=5166 comm="qemu-system-i38" scontext=unconfined_u:unconfined_r:svirt_t:s0:c68,c970 tcontext=unconfined_u:unconfined_r:svirt_t:s0:c68,c970 tclass=process
:
:
:Hash: qemu-system-i38,svirt_t,svirt_t,process,execmem
:
:audit2allow
:
:#============= svirt_t ==============
:#!!!! This avc can be allowed using the boolean 'virt_use_execmem'
:
:allow svirt_t self:process execmem;
:
:audit2allow -R
:
:#============= svirt_t ==============
:#!!!! This avc can be allowed using the boolean 'virt_use_execmem'
:
:allow svirt_t self:process execmem;
:
Comment 1 Christophe Fergeau 2012-10-02 12:45:26 EDT
Created attachment 620391 [details]
File: type
Comment 2 Christophe Fergeau 2012-10-02 12:45:35 EDT
Created attachment 620392 [details]
File: hashmarkername
Comment 3 Miroslav Grepl 2012-10-04 05:22:58 EDT
:#============= svirt_t ==============
:#!!!! This avc can be allowed using the boolean 'virt_use_execmem'
Comment 4 Christophe Fergeau 2012-10-04 05:42:03 EDT
(In reply to comment #3)
> :#============= svirt_t ==============
> :#!!!! This avc can be allowed using the boolean 'virt_use_execmem'

Doesn't this mean that non-kvm qemus are broken out of the box, and that this is done on purpose? This does not sound great from a user point of view...
Comment 5 Francisco de la Peña 2012-11-08 21:32:27 EST
Since 3.5.4 Boxes allows to create QEMU VMs without KVM capabilities:

http://ftp.acc.umu.se/pub/GNOME/sources/gnome-boxes/3.5/gnome-boxes-3.5.4.news
Comment 6 Daniel Walsh 2012-11-09 09:12:27 EST
Well open this up for discussion on the virt list.  I don't care either way.   Allowing virt to use execmem, makes it more susceptable to buffer overflow attacks.  I guess we could have libvirt set the boolean when running a qemu process without kvm or select a different svirt label svirt_nokvm_t.
Comment 7 Daniel Berrange 2012-11-09 11:55:15 EST
I would go for having a separate svirt label for non-KVM based QEMU.
Comment 8 Daniel Walsh 2012-11-13 09:21:43 EST
Ok I just checked changes into F18 policy to support to types svirt_t, and svirt_nokvm_t, only difference is execmem, and execstack for svirt_nokvm_t.

Context file has changed to include two labels.

cat virtual_domain_context 
system_u:system_r:svirt_t:s0
system_u:system_r:svirt_nokvm_t:s0

Now libvirt needs to change to be able to use the alternate label.
Comment 9 Jiri Eischmann 2012-11-20 17:50:00 EST
I was trying to create a virtual machine in Boxes.

Package: (null)
Architecture: x86_64
OS Release: Fedora release 18 (Spherical Cow)
Comment 10 Daniel Walsh 2012-11-21 05:45:32 EST
Jiri just turn on the boolean.
Comment 11 Cole Robinson 2012-12-12 09:59:14 EST

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