Bug 590713
| Summary: | SELinux is preventing /usr/bin/qemu-img "write" access to /home/dbeer/vms/livirt/images. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | David <david.m.beer> |
| Component: | libvirt | Assignee: | Daniel Veillard <veillard> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 13 | CC: | berrange, clalance, crobinso, dwalsh, itamar, jforbes, mgrepl, sassmann, veillard, virt-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | setroubleshoot_trace_hash:53ac546f741cb8a7fc56fc84cce06bd6da3803b3e5793836fbabd0e00aa7cb72 | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-05-18 16:15:52 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
tried to create a vmdk image in virt-manager Did you disable SELinux support in libvirt? No I haven't changed anything to do with SELinux Well libvirt should have been running your qemu process as svirt_t, so either SELInux is disabled in libvirt or we have a bug in libvirt. > Source Context system_u:system_r:qemu_t:s0-s0:c0.c1023
> Target Context unconfined_u:object_r:user_home_t:s0
> Target Objects /home/dbeer/vms/livirt/images [ dir ]
> Source qemu-img
> Source Path /usr/bin/qemu-img
This is not a virtual machine. The 'qemu-img' binary is a command line helper tool for formatting disks in non-raw formats, eg qcow2, vmdk, etc - think of it as a 'mkfs.ext3 / parted' but for virtual disk images. It is spawned by libvirtd and should probably inherit libvirtd context - it certainly shouldn't be running 'qemu_t' which is the generic QEMU virtual machine domain.
Ok so the labeling on /usr/bin/qemu-img should be bin_t not qemu_exec_t. Any others? /usr/bin/qemu system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-alpha system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-arm system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-armeb system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-cris system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-i386 system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-img system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-img-xen system_u:object_r:bin_t:s0 /usr/bin/qemu-io system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-kvm system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-launcher system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-m68k system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-mips system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-mipsel system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-nbd system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-nbd-xen system_u:object_r:bin_t:s0 /usr/bin/qemu-ppc system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-ppc64 system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-ppc64abi32 system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-sh4 system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-sh4eb system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-sparc system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-sparc32plus system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-sparc64 system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-arm system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-cris system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-m68k system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-mips system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-mips64 system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-mips64el system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-mipsel system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-ppc system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-ppc64 system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-ppcemb system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-sh4 system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-sh4eb system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-sparc system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-x86_64 system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-x86_64 system_u:object_r:qemu_exec_t:s0 Adding /usr/bin/qemu-img -- gen_context(system_u:object_r:bin_t,s0) /usr/bin/qemu-launcher -- gen_context(system_u:object_r:bin_t,s0) Only 'qemu', 'qemu-kvm' 'qemu-system-$ARCH' binaries provide the full virtual machine emulator. The plain 'qemu-$ARCH' are a different type of emulator. Instead of being a full machine emulator, they're a foreign binary emulator. eg you can install PPC fedora to '/opt/fedorappc' and then run 'qemu-ppc /opt/fedorappc/bin/ls'. For this to work the qemu$ARCH binaries effectively need to be unconfined since they can be used to run any binary at all. This capability isn't used by libvirt anyway. So IMHO everything except those ones I list in the first paragraph should be bin_t So keep these as qemu_exec_t: /usr/bin/qemu system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-kvm system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-arm system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-cris system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-m68k system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-mips system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-mips64 system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-mips64el system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-mipsel system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-ppc system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-ppc64 system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-ppcemb system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-sh4 system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-sh4eb system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-sparc system_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-system-x86_64 system_u:object_r:qemu_exec_t:s0 make the others bin_t (In reply to comment #4) > Well libvirt should have been running your qemu process as svirt_t, so either > SELInux is disabled in libvirt or we have a bug in libvirt. I have only installed the packages, never configured anything for SELinux. I have only added an additional pool for storing my vms. /usr/bin/qemu -- gen_context(system_u:object_r:qemu_exec_t,s0) /usr/bin/qemu-system-.* -- gen_context(system_u:object_r:qemu_exec_t,s0) /usr/bin/qemu-kvm -- gen_context(system_u:object_r:qemu_exec_t,s0) /usr/libexec/qemu.* -- gen_context(system_u:object_r:qemu_exec_t,s0) Ok new labeling above. Fixed in selinux-policy-3.7.19-15.fc13.noarch All other qemu will default back to bin_t. *** Bug 589900 has been marked as a duplicate of this bug. *** selinux-policy-3.7.19-15.fc13.noarch is on its way to stable, so closing this bug. |
Summary: SELinux is preventing /usr/bin/qemu-img "write" access to /home/dbeer/vms/livirt/images. Detailed Description: SELinux denied qemu access to /home/dbeer/vms/livirt/images. If this is a virtualization image, it has to have a file context label of virt_image_t. The system is setup to label image files in directory./var/lib/libvirt/images correctly. We recommend that you copy your image file to /var/lib/libvirt/images. If you really want to have your qemu image files in the current directory, you can relabel /home/dbeer/vms/livirt/images to be virt_image_t using chcon. You also need to execute semanage fcontext -a -t virt_image_t '/home/dbeer/vms/livirt/images' to add this new path to the system defaults. If you did not intend to use /home/dbeer/vms/livirt/images as a qemu image it could indicate either a bug or an intrusion attempt. Allowing Access: You can alter the file context by executing chcon -t virt_image_t '/home/dbeer/vms/livirt/images' You must also change the default file context files on the system in order to preserve them even on a full relabel. "semanage fcontext -a -t virt_image_t '/home/dbeer/vms/livirt/images'" Fix Command: chcon -t virt_image_t '/home/dbeer/vms/livirt/images' Additional Information: Source Context system_u:system_r:qemu_t:s0-s0:c0.c1023 Target Context unconfined_u:object_r:user_home_t:s0 Target Objects /home/dbeer/vms/livirt/images [ dir ] Source qemu-img Source Path /usr/bin/qemu-img Port <Unknown> Host (removed) Source RPM Packages qemu-img-0.12.3-8.fc13 Target RPM Packages Policy RPM selinux-policy-3.7.19-13.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name qemu_file_image Host Name (removed) Platform Linux (removed) 2.6.33.3-85.fc13.x86_64 #1 SMP Thu May 6 18:09:49 UTC 2010 x86_64 x86_64 Alert Count 2 First Seen Mon 10 May 2010 15:27:37 BST Last Seen Mon 10 May 2010 15:30:11 BST Local ID 2f5d2dd1-b097-4ed8-a195-c04a73d0ae23 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1273501811.94:74): avc: denied { write } for pid=20518 comm="qemu-img" name="images" dev=dm-0 ino=27132781 scontext=system_u:system_r:qemu_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir node=(removed) type=SYSCALL msg=audit(1273501811.94:74): arch=c000003e syscall=2 success=no exit=-13 a0=7ffffd6cde77 a1=241 a2=1a4 a3=d items=0 ppid=1610 pid=20518 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="qemu-img" exe="/usr/bin/qemu-img" subj=system_u:system_r:qemu_t:s0-s0:c0.c1023 key=(null) Hash String generated from qemu_file_image,qemu-img,qemu_t,user_home_t,dir,write audit2allow suggests: #============= qemu_t ============== #!!!! The source type 'qemu_t' can write to a 'dir' of the following types: # tmp_t, virt_image_type, var_t, tmpfs_t, var_run_t, qemu_tmp_t, virt_cache_t, qemu_image_t, qemu_tmpfs_t, qemu_var_run_t, cifs_t, dosfs_t, nfs_t allow qemu_t user_home_t:dir write;