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: | |||
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. |
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: <devices> <emulator>/home/rjones/d/libguestfs/tests/extra/qemu-wrapper.sh</emulator> 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 binary? Version-Release number of selected component (if applicable): libvirt from git (fbf9aa12c7e5ade035f208584b3a55401bc097a3) selinux-policy-3.11.1-7.fc18.noarch How reproducible: 100% 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.