Bug 871749
Summary: | qemu denied {open} access to filesystem | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Richard W.M. Jones <rjones> |
Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> |
Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 18 | CC: | berrange, clalancette, dominick.grift, dwalsh, itamar, jforbes, jyang, laine, libvirt-maint, mgrepl, 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: | 2013-02-28 10:06:12 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-10-31 10:04:44 UTC
Permissive mode is rate limited, so it shows the AVC only once,where as enforcing shows it everytime. This avc shows a confined virtual machine attempting to read a temporary file created by a user. To get this to work the tool would have to label the tempory file with something a confined app can read. selinux_virtual_image_context_path() Would tell you the file to read to get this path. cat /etc/selinux/targeted/contexts/virtual_image_context system_u:object_r:svirt_image_t:s0 system_u:object_r:virt_content_t:s0 The first field is readable by all svirt_t domains. If you want this to be particular to the current svirt domain then you would want to label your content to match the MCS label on the virtual machine. system_u:object_r:svirt_image_t:s0:c375,c469 I don't really understand comment 1, but does this mean it's a libvirt bug and that libvirt should be labelling this file? I will note that we recently changed libguestfs: Previously this file would have been passed to qemu using a command line argument of the form: -drive file=.../root.1234,snapshot=on This causes qemu to create a temporary qcow2 overlay backed by this file somewhere under $TMPDIR. After the change we now explicitly create the qcow2 overlay ourselves (ie. qemu-img create -f qcow2 -b .../root.1234 tempfile) and we pass this to qemu using an argument of the form: -drive file=tempfile This change may mean that libvirt is only seeing and labelling the overlay file. It doesn't see the backing file. (In reply to comment #2) > Previously > this file would have been passed to qemu [...] What I mean there is that we pass the filename to qemu via libvirt, using libvirt XML incantations that cause it to use that qemu argument. Yes so if libvirt is launching the qemu process than it needs to relabel it to a label that svirt_t can read. Currently you are handling a file to a confined virtual machine that looks like any random file created in the /tmp directory by any user on the system. Any content that is going to be used by the qemu/svirt_t process must be labeled by libvirt to a secure label. This has been fixed by Eric's patch below, because that indirectly ensures the appliance backing disk is relabelled. commit 82d5fe543720da6d83c1d6bfa1c347d7d9fda278 Author: Eric Blake <eblake> Date: Wed Feb 20 15:34:48 2013 -0700 qemu: check backing chains even when cgroup is omitted See also bug 896685. |