Description of problem: Running 'libguestfs-test-tool', with SELinux Enforcing fails with the following AVCs: type=AVC msg=audit(1351677485.714:2733): avc: denied { open } for pid=6283 comm="qemu-kvm" path="/home/rjones/d/libguestfs/tmp/.guestfs-1000/root.6222" dev="dm-6" ino=813643 scontext=unconfined_u:unconfined_r:svirt_t:s0:c375,c469 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1351677485.714:2733): arch=c000003e syscall=2 success=no exit=-13 a0=7fff70d09040 a1=80800 a2=0 a3=1 items=0 ppid=1 pid=6283 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=unconfined_u:unconfined_r:svirt_t:s0:c375,c469 key=(null) type=AVC msg=audit(1351677485.714:2734): avc: denied { open } for pid=6283 comm="qemu-kvm" path="/home/rjones/d/libguestfs/tmp/.guestfs-1000/root.6222" dev="dm-6" ino=813643 scontext=unconfined_u:unconfined_r:svirt_t:s0:c375,c469 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1351677485.714:2734): arch=c000003e syscall=2 success=no exit=-13 a0=7fff70d09040 a1=80800 a2=0 a3=1 items=0 ppid=1 pid=6283 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=unconfined_u:unconfined_r:svirt_t:s0:c375,c469 key=(null) type=AVC msg=audit(1351677485.714:2735): avc: denied { open } for pid=6283 comm="qemu-kvm" path="/home/rjones/d/libguestfs/tmp/.guestfs-1000/root.6222" dev="dm-6" ino=813643 scontext=unconfined_u:unconfined_r:svirt_t:s0:c375,c469 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1351677485.714:2735): arch=c000003e syscall=2 success=no exit=-13 a0=7fff70d09040 a1=80000 a2=0 a3=48 items=0 ppid=1 pid=6283 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=unconfined_u:unconfined_r:svirt_t:s0:c375,c469 key=(null) Strangely setting SELinux to Permissive results in fewer AVCs. The operation also succeeds when permissive, so it does appear to be an SELinux policy problem. type=AVC msg=audit(1351677633.120:2758): avc: denied { open } for pid=7015 comm="qemu-kvm" path="/home/rjones/d/libguestfs/tmp/.guestfs-1000/root.6954" dev="dm-6" ino=812155 scontext=unconfined_u:unconfined_r:svirt_t:s0:c338,c736 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1351677633.120:2758): arch=c000003e syscall=2 success=yes exit=15 a0=7fffe3829a70 a1=80800 a2=0 a3=1 items=0 ppid=1 pid=7015 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=unconfined_u:unconfined_r:svirt_t:s0:c338,c736 key=(null) Version-Release number of selected component (if applicable): selinux-policy-3.11.1-43.fc18.noarch libvirt-0.10.2-3.fc18.x86_64 libguestfs-1.19.55-1.fc18.x86_64 How reproducible: 100% Steps to Reproduce: 1. Run libguestfs-test-tool.
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.