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;
Should I don't audit this? Or is this a bug? Or do I need to allow this?
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.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
(In reply to comment #2) > Tim, are you running qemu directly? Can you give us the command line? No, I'm using virt-manager.
Could you fetch the qemu command line that virt-manager uses to launch the vm? Should be in the libvirt logs.
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
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.
Bug still valid with Fedora 15.
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
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.