Bug 1064375 - SELinux is preventing /usr/bin/qemu-system-x86_64 from 'read' accesses on the file kernel.18148.
Summary: SELinux is preventing /usr/bin/qemu-system-x86_64 from 'read' accesses on the...
Keywords:
Status: CLOSED CURRENTRELEASE
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:73b8315a59abeee67870efe96ff...
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs
TreeView+ depends on / blocked
 
Reported: 2014-02-12 13:50 UTC by Richard W.M. Jones
Modified: 2016-04-27 01:11 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-26 15:12:11 UTC
Type: ---


Attachments (Terms of Use)

Description Richard W.M. Jones 2014-02-12 13:50:54 UTC
Description of problem:
It's unclear what exactly went wrong here.

I was running the libguestfs test suite, when this error was printed:

-----------
libguestfs: error: could not create appliance through libvirt.

Try running qemu directly without libvirt using this environment variable:
export LIBGUESTFS_BACKEND=direct

Original error from libvirt: internal error: process exited while connecting to monitor: qemu: could not load kernel '/home/rjones/d/libguestfs-1.24/tmp/.guestfs-1000/kernel.18148': Permission denied
 [code=1 domain=10]
libguestfs: error: could not create appliance through libvirt.

Try running qemu directly without libvirt using this environment variable:
export LIBGUESTFS_BACKEND=direct

Original error from libvirt: internal error: early end of file from monitor: possible problem:
qemu: could not load kernel '/home/rjones/d/libguestfs-1.24/tmp/.guestfs-1000/kernel.18148': Permission denied
 [code=1 domain=10]
-----------

It is possible this is some kind of race between threads in libvirt (or libguestfs).
SELinux is preventing /usr/bin/qemu-system-x86_64 from 'read' accesses on the file kernel.18148.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that qemu-system-x86_64 should be allowed read access on the kernel.18148 file 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                unconfined_u:system_r:svirt_t:s0:c214,c981
Target Context                unconfined_u:object_r:user_home_t:s0
Target Objects                kernel.18148 [ file ]
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-3.fc20.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-106.fc20.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.12.5-302.fc20.x86_64 #1 SMP Tue
                              Dec 17 20:42:32 UTC 2013 x86_64 x86_64
Alert Count                   1
First Seen                    2014-02-12 13:47:15 GMT
Last Seen                     2014-02-12 13:47:15 GMT
Local ID                      28adbb9f-f1d1-403e-a94d-c87d3f8cfc9a

Raw Audit Messages
type=AVC msg=audit(1392212835.683:3028): avc:  denied  { read } for  pid=18474 comm="qemu-system-x86" name="kernel.18148" dev="sdb1" ino=799903 scontext=unconfined_u:system_r:svirt_t:s0:c214,c981 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file


type=SYSCALL msg=audit(1392212835.683:3028): arch=x86_64 syscall=open success=no exit=EACCES a0=7f6ad9f5d8d0 a1=0 a2=1b6 a3=1 items=0 ppid=1 pid=18474 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 ses=1 tty=(none) comm=qemu-system-x86 exe=/usr/bin/qemu-system-x86_64 subj=unconfined_u:system_r:svirt_t:s0:c214,c981 key=(null)

Hash: qemu-system-x86,svirt_t,user_home_t,file,read

Additional info:
reporter:       libreport-2.1.10
hashmarkername: setroubleshoot
kernel:         3.12.5-302.fc20.x86_64
type:           libreport

Potential duplicate: bug 988996

Comment 1 Richard W.M. Jones 2014-02-12 14:22:31 UTC
Another thought about this bug:

I was running two separate sets of libguestfs tests.  These use
different directories, and therefore different appliances, kernels etc.

However because of the design of libvirt, they will share a single
libvirtd process.

Comment 2 Daniel Walsh 2014-02-14 17:28:57 UTC
It looks like the kernel.18148 was not relabeled.

Comment 3 Richard W.M. Jones 2014-02-14 17:45:29 UTC
.. which would be a libvirt bug, since it's supposed to be
doing the labelling.

There is at least one known race in libvirt labelling (bug 871196).
However I'm fairly sure this can't be the same thing.

Comment 4 M. Edward (Ed) Borasky 2014-07-13 06:55:51 UTC
Description of problem:
Starting up VirtManager

Additional info:
reporter:       libreport-2.2.2
hashmarkername: setroubleshoot
kernel:         3.15.3-200.fc20.x86_64
type:           libreport

Comment 5 lasse.schuirmann 2014-11-25 19:27:23 UTC
Description of problem:
1. Compile gnome-boxes from git on fedora 20
2. Create a VM in Boxes
3. Click on the VM to start it

Additional info:
reporter:       libreport-2.2.3
hashmarkername: setroubleshoot
kernel:         3.11.10-301.fc20.x86_64
type:           libreport

Comment 6 Cole Robinson 2015-04-25 22:42:33 UTC
Unfortunately a couple other hits have latched onto this bug, but I'm guessing the symptom is not the same as Rich's original report.

Rich, do you still these AVCs with the libguestfs test suite and newer libvirt?

Comment 7 Richard W.M. Jones 2015-04-26 08:14:05 UTC
No.


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