Bug 570427 - SELinux is preventing /usr/bin/qemu-kvm "setrlimit" access .
Summary: SELinux is preventing /usr/bin/qemu-kvm "setrlimit" access .
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 15
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Fedora Virtualization Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:0ff4d715bfc...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-04 10:23 UTC by Tim Waugh
Modified: 2013-01-09 22:20 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-29 00:11:30 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Tim Waugh 2010-03-04 10:23:49 UTC
Summary:

SELinux is preventing /usr/bin/qemu-kvm "setrlimit" access .

Detailed Description:

SELinux denied access requested by qemu-kvm. It is not expected that this access
is required by qemu-kvm and this access may signal an intrusion attempt. It is
also possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug
report.

Additional Information:

Source Context                system_u:system_r:svirt_t:s0:c92,c904
Target Context                system_u:system_r:svirt_t:s0:c92,c904
Target Objects                None [ process ]
Source                        qemu-kvm
Source Path                   /usr/bin/qemu-kvm
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           qemu-system-x86-0.12.3-3.fc13
Target RPM Packages           
Policy RPM                    selinux-policy-3.7.10-4.fc13
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     (removed)
Platform                      Linux (removed) 2.6.33-1.fc13.x86_64 #1 SMP Wed Feb
                              24 19:55:32 UTC 2010 x86_64 x86_64
Alert Count                   1
First Seen                    Thu 04 Mar 2010 10:17:49 GMT
Last Seen                     Thu 04 Mar 2010 10:17:49 GMT
Local ID                      cb0c8ac5-7bc7-4e2e-bd1a-a7f090bdbebb
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1267697869.570:32889): avc:  denied  { setrlimit } for  pid=4466 comm="qemu-kvm" scontext=system_u:system_r:svirt_t:s0:c92,c904 tcontext=system_u:system_r:svirt_t:s0:c92,c904 tclass=process

node=(removed) type=SYSCALL msg=audit(1267697869.570:32889): arch=c000003e syscall=160 success=no exit=-13 a0=4 a1=7fffbd006720 a2=0 a3=3d65818230 items=0 ppid=4465 pid=4466 auid=500 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=1 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c92,c904 key=(null)



Hash String generated from  catchall,qemu-kvm,svirt_t,svirt_t,process,setrlimit
audit2allow suggests:

#============= svirt_t ==============
allow svirt_t self:process setrlimit;

Comment 1 Daniel Walsh 2010-03-04 13:17:15 UTC
Should I don't audit this?  Or is this a bug?  Or do I need to allow this?

Comment 2 Amit Shah 2010-03-09 15:52:17 UTC
Tim, are you running qemu directly? Can you give us the command line?

I don't see any setrlimit calls in any relevant qemu-kvm code; so this looks spurious.

Comment 3 Fedora Admin XMLRPC Client 2010-03-09 16:51:07 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Fedora Admin XMLRPC Client 2010-03-09 16:51:37 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 5 Fedora Admin XMLRPC Client 2010-03-09 16:52:59 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 6 Fedora Admin XMLRPC Client 2010-03-09 17:19:37 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 7 Tim Waugh 2010-03-10 09:30:10 UTC
(In reply to comment #2)
> Tim, are you running qemu directly? Can you give us the command line?

No, I'm using virt-manager.

Comment 8 Amit Shah 2010-03-26 03:33:55 UTC
Could you fetch the qemu command line that virt-manager uses to launch the vm? Should be in the libvirt logs.

Comment 9 Michal Schmidt 2010-08-01 08:44:32 UTC
I'm seeing the same denial. I'm creating a new guest using virt-manager.
From /var/log/libvirt/qemu/F-branched-32.log:

LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -S -M fedora-13 -enable-kvm -m 1024 -smp 3,sockets=3,cores=1,threads=1 -name F-branched-32 -uuid cf2ff5d7-6a15-7630-8e35-e668f5c5e94a -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/F-branched-32.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=utc -no-reboot -boot c -kernel /home/michich/.virtinst/boot/virtinst-vmlinuz.S35WKq -initrd /home/michich/.virtinst/boot/virtinst-initrd.img.80koWC -append method=http://mirror.karneval.cz/pub/fedora/releases/13/Fedora/i386/os/ -drive file=/dev/mapper/nonraidvg-vF--branched--32,if=none,id=drive-virtio-disk0,boot=on,format=raw -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:32:ec:ac,bus=pci.0,addr=0x5 -net tap,fd=54,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x6 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3

Comment 10 Michal Schmidt 2010-08-01 08:47:41 UTC
I have these package versions:
qemu-system-x86-0.12.3-8.fc13.x86_64
libvirt-0.8.2-1.fc13.x86_64
virt-manager-0.8.4-2.fc13.noarch
selinux-policy-targeted-3.7.19-39.fc13.noarch
kernel-2.6.35-0.56.rc6.git1.fc14.x86_64

I should add that the denial does not prevent the guest from starting and working fine.

Comment 11 Michael S. 2011-05-26 08:57:49 UTC
Bug still valid with Fedora 15.

Comment 12 Bug Zapper 2011-06-02 16:20:00 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 13 Fedora Admin XMLRPC Client 2012-03-15 17:54:48 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 14 Cole Robinson 2012-05-29 00:11:30 UTC
Given that F15 is end of life in less than a month, it's unlikely this will get fixed before then. If anyone is still seeing this issue on F16 or later, please reopen and we can go from there.


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