This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 445848 - Could not use kqemu with SELinux in enforcing mode
Could not use kqemu with SELinux in enforcing mode
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-09 08:10 EDT by Mihai Harpau
Modified: 2008-11-17 17:03 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-17 17:03:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
audit log (913.94 KB, text/plain)
2008-05-09 10:08 EDT, Mihai Harpau
no flags Details

  None (edit)
Description Mihai Harpau 2008-05-09 08:10:13 EDT
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:
Comment 1 Mihai Harpau 2008-05-09 09:11:21 EDT
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 };
Comment 2 Daniel Walsh 2008-05-09 09:41:36 EDT
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.



Comment 3 Mihai Harpau 2008-05-09 10:08:59 EDT
Created attachment 304944 [details]
audit log
Comment 4 Mihai Harpau 2008-05-09 10:34:43 EDT
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)

Comment 5 Mihai Harpau 2008-05-09 10:41:22 EDT
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
Comment 6 Mihai Harpau 2008-05-09 12:09:05 EDT
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

'
Comment 7 Bug Zapper 2008-05-14 06:54:46 EDT
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
Comment 8 Jan Hutař 2008-06-05 03:37:21 EDT
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?
Comment 9 Daniel Walsh 2008-07-02 15:39:05 EDT
Fixed in selinux-policy-3.3.1-74.fc9.noarch
Comment 10 Daniel Walsh 2008-11-17 17:03:42 EST
Closing all bugs that have been in modified for over a month.  Please reopen if the bug is not actually fixed.

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