Bug 857659
Summary: | sVirt denies execution of custom <emulator> | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Richard W.M. Jones <rjones> |
Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | berrange, clalancette, crobinso, itamar, jforbes, jyang, laine, libvirt-maint, veillard, virt-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-10-02 00:21:20 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Richard W.M. Jones
2012-09-15 16:25:00 UTC
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. > 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 ?
It's a feature of libguestfs that you can use custom QEMU http://libguestfs.org/guestfs.3.html#qemu-wrappers 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. 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. I've done what was suggested in comment 4: https://github.com/libguestfs/libguestfs/commit/2e17d78178eb085bdf54eb170bf036e0d7143c19 Sounds like NOTABUG for libvirt? Closing as such, feel free to reopen if I'm wrong. |