Bug 857659

Summary: sVirt denies execution of custom <emulator>
Product: [Fedora] Fedora Reporter: Richard W.M. Jones <rjones>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: berrange, clalancette, crobinso, itamar, jforbes, jyang, laine, libvirt-maint, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-10-01 20:21:20 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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.