Bug 857659 - sVirt denies execution of custom <emulator>
sVirt denies execution of custom <emulator>
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-09-15 12:25 EDT by Richard W.M. Jones
Modified: 2012-10-01 20:21 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-10-01 20:21:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Richard W.M. Jones 2012-09-15 12:25:00 EDT
Description of problem:

If I use a custom <emulator>, then SELinux denies it:

type=AVC msg=audit(1347725877.798:7047): avc:  denied  { entrypoint } for  pid=987 comm="lt-libvirtd" path="/home/rjones/d/libguestfs/tests/extra/qemu-wrapper.sh" dev="dm-5" ino=537232 scontext=unconfined_u:unconfined_r:svirt_t:s0:c396,c1005 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

This emulator appears in the libvirt XML as:


Obviously I want to execute it, else I wouldn't have put it
in the XML!

audit2allow suggests:
allow svirt_t user_home_t:file entrypoint;

Should I (and can I?) label the emulator?  Should libvirt label it?
Should sVirt be more permissive and allow libvirt to execute any

Version-Release number of selected component (if applicable):

libvirt from git (fbf9aa12c7e5ade035f208584b3a55401bc097a3)

How reproducible:


Steps to Reproduce:
1. Enable SELinux.
2. Create a transient guest with custom <emulator>
3. Start guest.
Actual results:

Fails with the error message:
libvir:  error : cannot execute binary /home/rjones/d/libguestfs/tests/extra/qemu-wrapper.sh: Permission denied
+ audit log as above.

Expected results:

Should be able to execute it.
Comment 1 Richard W.M. Jones 2012-09-15 12:35:56 EDT
A simple attempt to work around this by labelling the
emulator with system_u:object_r:qemu_exec_t:s0 (same
as real qemu) didn't work.  The reason is because that
label cannot execute the real qemu-system-x86_64.

What we really need is some sort of transition back
to an unconfined process, since the qemu wrapper can
(and should) be able to do anything.
Comment 2 Daniel Berrange 2012-09-17 04:55:57 EDT
> What we really need is some sort of transition back
> to an unconfined process, since the qemu wrapper can
> (and should) be able to do anything.

From the point where libvirt exec() the <emulator> binary, we have to assume the process is now untrusted / malicious. If we allowed it to exec other QEMU binaries to make a shell wrapper script work, we would also by implication, be allowing a compromised/malicious QEMU process to exec() other QEMU binaries. This is not something we can allow in the SELinux policy. For this reason we don't consider shell wrapper scripts to be something supportable outside a dev environment for ad-hoc testing.  What are you trying to do with the wrapper script that is not possible to express in the XML already ?
Comment 3 Richard W.M. Jones 2012-09-17 05:23:09 EDT
It's a feature of libguestfs that you can use custom QEMU
That doesn't mean we have to support this feature from libguestfs
when users choose the libvirt backend, although it'd certainly be nice.

I'm using it in the libguestfs extra-tests suite, which is the
super-comprehensive test suite that runs everything under valgrind
and against upstream qemu (keeping an eye on whether upstream qemu
has broken things again, before it gets into Fedora).

Can't we have some sort of label for the custom qemu script?
That would mean users would have to take an extra step -- labelling --
before <emulator> would work, but would allow people to use
a custom qemu even with SELinux in Enforcing mode.
Comment 4 Daniel Berrange 2012-09-17 05:25:44 EDT
If this is a edge-case rarely used feature, one option might be to simply mark the guest in question as non-confined by SELinux by using <seclabel model='none'/> in the XML, when using a shell wrapper script.
Comment 5 Richard W.M. Jones 2012-09-17 08:56:07 EDT
I've done what was suggested in comment 4:
Comment 6 Cole Robinson 2012-10-01 20:21:20 EDT
Sounds like NOTABUG for libvirt? Closing as such, feel free to reopen if I'm wrong.

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