Description of problem: Summary: SELinux is preventing qemu (qemu_t) "read write" access to device kqemu. Detailed Description: SELinux has denied the qemu (qemu_t) "read write" access to device kqemu. kqemu is mislabeled, this device has the default label of the /dev directory, which should not happen. All Character and/or Block Devices should have a label. You can attempt to change the label of the file using restorecon -v 'kqemu'. If this device remains labeled device_t, then this is a bug in SELinux policy. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against the selinux-policy package. If you look at the other similar devices labels, ls -lZ /dev/SIMILAR, and find a type that would work for kqemu, you can use chcon -t SIMILAR_TYPE 'kqemu', If this fixes the problem, you can make this permanent by executing semanage fcontext -a -t SIMILAR_TYPE 'kqemu' If the restorecon changes the context, this indicates that the application that created the device, created it without using SELinux APIs. If you can figure out which application created the device, please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this application. Allowing Access: Attempt restorecon -v 'kqemu' or chcon -t SIMILAR_TYPE 'kqemu' Additional Information: Source Context system_u:system_r:qemu_t:s0 Target Context system_u:object_r:device_t:s0 Target Objects kqemu [ chr_file ] Source qemu Source Path /usr/bin/qemu Port <Unknown> Host sysop Source RPM Packages qemu-0.9.1-5.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-42.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name device Host Name sysop Platform Linux sysop 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT 2008 i686 i686 Alert Count 2 First Seen Vi 09 mai 2008 14:41:11 +0000 Last Seen Vi 09 mai 2008 14:52:30 +0000 Local ID c18890ac-cd4e-4fc2-a14a-280560289afb Line Numbers Raw Audit Messages host=sysop type=AVC msg=audit(1210333950.905:69): avc: denied { read write } for pid=16852 comm="qemu" name="kqemu" dev=tmpfs ino=7035 scontext=system_u:system_r:qemu_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file host=sysop type=SYSCALL msg=audit(1210333950.905:69): arch=40000003 syscall=5 success=no exit=-13 a0=812aa21 a1=8002 a2=0 a3=8002 items=0 ppid=2550 pid=16852 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="qemu" exe="/usr/bin/qemu" subj=system_u:system_r:qemu_t:s0 key=(null) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I could use kqemu if build a local selinux policy module that contains: module local 1.0; require { type user_home_t; type device_t; type qemu_t; type tmpfs_t; class chr_file { read write ioctl }; class file { read write getattr create }; class dir { read write add_name setattr }; class filesystem getattr; } #============= qemu_t ============== allow qemu_t device_t:chr_file { read write ioctl }; allow qemu_t tmpfs_t:dir { write add_name }; allow qemu_t tmpfs_t:file create; allow qemu_t tmpfs_t:filesystem getattr; allow qemu_t user_home_t:file { read write getattr };
Please attach the audit log used to create this report. I will add a type for /dev/kqemu and allow qemu to read/write it. Not sure about tmpfs_t? What is it tryint to do here? Also allowing it to write to the homedir might be a problem. Later policies transition to unconfined_qemu_t if you have the boolean allow_unconfined_qemu_transition turned off.
Created attachment 304944 [details] audit log
The following lines: allow qemu_t tmpfs_t:dir { write add_name }; allow qemu_t tmpfs_t:file create; allow qemu_t tmpfs_t:filesystem getattr; seems to be generated by the following selinux alerts: 1) first one Summary: SELinux is preventing qemu (qemu_t) "getattr" to / (tmpfs_t). Detailed Description: SELinux denied access requested by qemu. It is not expected that this access is required by qemu 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://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:qemu_t:s0 Target Context system_u:object_r:tmpfs_t:s0 Target Objects / [ filesystem ] Source qemu Source Path /usr/bin/qemu Port <Unknown> Host sysop Source RPM Packages qemu-0.9.1-5.fc9 Target RPM Packages filesystem-2.4.13-1.fc9 Policy RPM selinux-policy-3.3.1-42.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name sysop Platform Linux sysop 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT 2008 i686 i686 Alert Count 1 First Seen Vi 09 mai 2008 17:26:09 +0000 Last Seen Vi 09 mai 2008 17:26:09 +0000 Local ID d5ec54dd-1578-4011-81b4-6813bad8527c Line Numbers Raw Audit Messages host=sysop type=AVC msg=audit(1210343169.617:125): avc: denied { getattr } for pid=27993 comm="qemu" name="/" dev=tmpfs ino=6796 scontext=system_u:system_r:qemu_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem host=sysop type=SYSCALL msg=audit(1210343169.617:125): arch=40000003 syscall=268 success=no exit=-13 a0=8118ffa a1=54 a2=bfcf85e0 a3=bfcf8f61 items=0 ppid=2550 pid=27993 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="qemu" exe="/usr/bin/qemu" subj=system_u:system_r:qemu_t:s0 key=(null) 2) second one Summary: SELinux is preventing qemu (qemu_t) "write" to / (tmpfs_t). Detailed Description: SELinux denied access requested by qemu. It is not expected that this access is required by qemu 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: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /, restorecon -v '/' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:qemu_t:s0 Target Context system_u:object_r:tmpfs_t:s0 Target Objects / [ dir ] Source qemu Source Path /usr/bin/qemu Port <Unknown> Host sysop Source RPM Packages qemu-0.9.1-5.fc9 Target RPM Packages filesystem-2.4.13-1.fc9 Policy RPM selinux-policy-3.3.1-42.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name sysop Platform Linux sysop 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT 2008 i686 i686 Alert Count 1 First Seen Vi 09 mai 2008 17:26:09 +0000 Last Seen Vi 09 mai 2008 17:26:09 +0000 Local ID 5e30b7e4-0a2d-43ac-9cbc-5b94ba22ba51 Line Numbers Raw Audit Messages host=sysop type=AVC msg=audit(1210343169.617:126): avc: denied { write } for pid=27993 comm="qemu" name="/" dev=tmpfs ino=6796 scontext=system_u:system_r:qemu_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir host=sysop type=SYSCALL msg=audit(1210343169.617:126): arch=40000003 syscall=5 success=no exit=-13 a0=bfcf8640 a1=80c2 a2=180 a3=f371f items=0 ppid=2550 pid=27993 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="qemu" exe="/usr/bin/qemu" subj=system_u:system_r:qemu_t:s0 key=(null)
The line allow qemu_t user_home_t:file { read write getattr }; could be generated by the fact that iso image from what I installed WinXP in VM guest does not have the correct selinux context (virt_image_t) and also iso image stay in user's home
I make another test: install F9-preview in /home/mihai/f9.img I see the following error from virt-manager that disapear if I relabel iso image with the right context (virt_image_t): Unable to complete install '<class 'libvirt.libvirtError'> virDomainCreateLinux() failed internal error QEMU quit during console startup warning: could not create temporary file in '/dev/shm'. Use QEMU_TMPDIR to select a directory in a tmpfs filesystem. Using '/tmp' as fallback. qemu: could not open disk image /home/mihai/linux/distributii/Fedora-9-Preview-i386-DVD/Fedora-9-Preview-i386-DVD.iso Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/create.py", line 651, in do_install dom = guest.start_install(False, meter = meter) File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 845, in start_install return self._do_install(consolecb, meter) File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 866, in _do_install self.domain = self.conn.createLinux(install_xml, 0) File "/usr/lib/python2.5/site-packages/libvirt.py", line 833, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: virDomainCreateLinux() failed internal error QEMU quit during console startup warning: could not create temporary file in '/dev/shm'. Use QEMU_TMPDIR to select a directory in a tmpfs filesystem. Using '/tmp' as fallback. qemu: could not open disk image /home/mihai/linux/distributii/Fedora-9-Preview-i386-DVD/Fedora-9-Preview-i386-DVD.iso '
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Hello, this is still an issue with (I'm using virt-manager): selinux-policy-3.3.1-55.fc9.noarch selinux-policy-targeted-3.3.1-55.fc9.noarch kvm-65-7.fc9.x86_64 libvirt-0.4.2-3.fc9.x86_64 qemu-0.9.1-5.fc9.x86_64 virt-manager-0.5.4-4.fc9.x86_64 I'm not sure if this should be reported against selinux-policy, maybe directly qemu?
Fixed in selinux-policy-3.3.1-74.fc9.noarch
Closing all bugs that have been in modified for over a month. Please reopen if the bug is not actually fixed.