Bug 1029328 - SELinux is preventing /usr/bin/qemu-system-x86_64 from using the 'execmem' accesses on a process.
Summary: SELinux is preventing /usr/bin/qemu-system-x86_64 from using the 'execmem' ac...
Keywords:
Status: CLOSED DUPLICATE of bug 966695
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 20
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:ac65e9d2c4559f1e3eef8263e1e...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-12 07:53 UTC by Vratislav Podzimek
Modified: 2014-05-01 21:11 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-12 10:31:43 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Vratislav Podzimek 2013-11-12 07:53:45 UTC
Description of problem:
Tried to start a VM in virt-manager.
SELinux is preventing /usr/bin/qemu-system-x86_64 from using the 'execmem' accesses on a process.

*****  Plugin catchall_boolean (89.3 confidence) suggests   ******************

If you want to allow confined virtual guests to use executable memory and executable stack
Then you must tell SELinux about this by enabling the 'virt_use_execmem' boolean.
You can read 'svirt_selinux' man page for more details.
Do
setsebool -P virt_use_execmem 1

*****  Plugin catchall (11.6 confidence) suggests   **************************

If you believe that qemu-system-x86_64 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-x86 /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:svirt_t:s0:c550,c650
Target Context                system_u:system_r:svirt_t:s0:c550,c650
Target Objects                 [ process ]
Source                        qemu-system-x86
Source Path                   /usr/bin/qemu-system-x86_64
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           qemu-system-x86-1.6.1-1.fc20.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-90.fc20.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 3.11.7-300.fc20.x86_64 #1 SMP Mon
                              Nov 4 15:07:39 UTC 2013 x86_64 x86_64
Alert Count                   1
First Seen                    2013-11-12 08:50:34 CET
Last Seen                     2013-11-12 08:50:34 CET
Local ID                      66020c77-74ec-47c9-9bb5-462af22e9208

Raw Audit Messages
type=AVC msg=audit(1384242634.131:675): avc:  denied  { execmem } for  pid=10345 comm="qemu-system-x86" scontext=system_u:system_r:svirt_t:s0:c550,c650 tcontext=system_u:system_r:svirt_t:s0:c550,c650 tclass=process


type=SYSCALL msg=audit(1384242634.131:675): arch=x86_64 syscall=mmap success=yes exit=140679426785280 a0=7ff27b42c000 a1=3d000 a2=7 a3=812 items=0 ppid=1 pid=10345 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 ses=4294967295 tty=(none) comm=qemu-system-x86 exe=/usr/bin/qemu-system-x86_64 subj=system_u:system_r:svirt_t:s0:c550,c650 key=(null)

Hash: qemu-system-x86,svirt_t,svirt_t,process,execmem

Additional info:
reporter:       libreport-2.1.9
hashmarkername: setroubleshoot
kernel:         3.11.7-300.fc20.x86_64
type:           libreport

Potential duplicate: bug 799169

Comment 1 Miroslav Grepl 2013-11-12 10:31:43 UTC
If you want to allow confined virtual guests to use executable memory and executable stack
Then you must tell SELinux about this by enabling the 'virt_use_execmem' boolean.
You can read 'svirt_selinux' man page for more details.
Do


setsebool -P virt_use_execmem 1

Comment 2 Vratislav Podzimek 2013-11-13 12:18:42 UTC
Well, my only problem with this is that in default installation, one cannot start a VM. That's definitely quite a serious issue.

Comment 3 Daniel Walsh 2013-11-13 21:47:58 UTC
Well you can start almost all vms from the default install.  You happen to be using one that we would like to avoid.

qemu-kvm works correctly out of the box.  One potential solution would be to get libvirt to change the type that it launches these qemu processes with to something other then svirt_t.

Comment 4 Vratislav Podzimek 2013-11-14 06:05:43 UTC
(In reply to Daniel Walsh from comment #3)
> Well you can start almost all vms from the default install.  You happen to
> be using one that we would like to avoid.
> 
> qemu-kvm works correctly out of the box.  One potential solution would be to
> get libvirt to change the type that it launches these qemu processes with to
> something other then svirt_t.
May I ask what's wrong/special with the virtual machine I run or with the way I'm running it? I'm not aware of anything like that and I know that on F17 those VMs worked without any issues.

Comment 5 Daniel Walsh 2013-11-18 14:28:21 UTC
I guess this is more a question that would need to be addressed towards qemu/libvirt then selinux-policy.

Comment 6 Daniel Berrangé 2013-11-18 14:38:13 UTC
If the VM is using KVM then 'execmem' should not be required & thus denial is absolutely correct for the 'svirt_t' type.  If not using KVM, then the QEMU TCG emulator does require 'execmem' and in this case libvirt should have already used 'svirt_tcg_t' which does permit it.

Comment 7 Daniel Berrangé 2013-11-19 18:37:56 UTC
I think this is probably the same issue as this bug

https://bugzilla.redhat.com/show_bug.cgi?id=966695

where the user had NVidia proprietary drivers from rpmfusion installed, whose libGL.so requires execmem.

We definitely don't want to allow this in QEMU policy for SELinux. I wonder if there is something that can be done with setroubleshoot to detect that the user is using  Nvidia proprietary modules.

Comment 8 Cole Robinson 2013-11-19 20:58:45 UTC

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

Comment 9 Daniel Walsh 2013-11-19 21:48:37 UTC
How do I determine if the NVidia drivers are being used?

Comment 10 Vratislav Podzimek 2013-11-20 07:41:24 UTC
(In reply to Daniel Walsh from comment #9)
> How do I determine if the NVidia drivers are being used?
There definitely is a way, because ABRT does it for kernel oops. Jakub, could you please help us here?

Comment 11 Jakub Filak 2013-11-20 08:53:17 UTC
(In reply to Vratislav Podzimek from comment #10)
> (In reply to Daniel Walsh from comment #9)
> > How do I determine if the NVidia drivers are being used?
> There definitely is a way, because ABRT does it for kernel oops. Jakub,
> could you please help us here?

In case of kernel oopses, ABRT can determine that a module was loaded because there is a line with all loaded modules and a line with the tainted flag in the kernel oops text. These information are also available at run time and can be found in /proc directory. /proc/modules contains all loaded modules (or lsmod provides the same information) and /proc/sys/kernel/tainted holds a value of the tainted flag. If you want to know whether a proprietary module was loaded, just check the 0th bit [1][2] of the tainted flag.


1: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/kernel.h#n417
2: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/kernel/panic.c?id=HEAD


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