Bug 551397
Summary: | libvirt shouldn't have to relabel public_content_t | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | John L Magee <jlmagee> |
Component: | libvirt | Assignee: | Eric Blake <eblake> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | berrange, c.geissler-hinteruhlberg, clalance, crobinso, dwalsh, eblake, itamar, jforbes, jimb5640, mgrepl, veillard, virt-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | setroubleshoot_trace_hash:dfdcb41441bb4119f4d50403fd82c07a590543b2d444947483e35c096558dbfa | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-01-12 00:26:12 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: |
Description
John L Magee
2009-12-30 13:31:44 UTC
I am not sure if the device got mislabeled after libvirt started the image. Did you insert the cdrom after the virtual machine was running? libvirt is supposed to label the device, but if udev came in and relabeled it, this could happen. I believe in this particular case, I did insert the data DVD after the VM was running. However, I get the same or similar failures even if the device is connected while the VM is shut down and then the VM is booted. This failure occurs on a Lenovo T500 with a SATA CD/DVD drive. I have a nearly identical installation on a Lenovo T61p with IDE CD/DVD and can dynamically connect and disconnect the drive with no problem. *** Bug 568763 has been marked as a duplicate of this bug. *** I think we just need to add miscfiles_read_public_files(virt_domain) storage_raw_read_removable_device(virt_domain) To allow svirt_t to read files labeled as public_content_t blk devices labeled as removable_t. Maybe add a boolean to read public_content and turn on by default. virt_use_public_content or something like that. But a bigger problem comes up when libvirt relabels public_content_t or removable_device_t to svirt_content_t. This will prevent other apps from using the content. Anyone currently having this problem can build a custom policy module to allow this access # cat > mysvirt.te << _EOF policy_module(mysvirt, 1.0) gen_require(` type svirt_t; ') miscfiles_read_public_files(svirt_t) storage_raw_read_removable_device(svirt_t) _EOF # make -f /usr/share/selinux/devel/Makefile # semodule -i mysvirt.pp Hmm, how does libvirt determine what selinux labels qemu can access? Is there a programmatic way, or is this all hardcoded somewhere? It would suck if libvirt had to be patched to leave public_content_t alone. Yes it can check programatically For example sesearch -A -s svirt_t -t public_content_t -p read Returns nothing, versus # sesearch -A -s svirt_t -t usr_t -p read Found 3 semantic av rules: allow virt_domain usr_t : file { ioctl read getattr lock open } ; allow virt_domain usr_t : dir { ioctl read getattr lock search open } ; allow virt_domain usr_t : lnk_file { read getattr } ; Another choice would be to not relabel read/only content and rely on the administrator labeling stuff correctly and selinux-policy allowing miscfiles_read_public_files(virt_domain) storage_raw_read_removable_device(virt_domain) THen removeable_t labeled by udev and admins labeling public_content_t would just work. I am not sure what is best here. This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping I assume this is still a problem for f14, so reassigning. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reassigning to rawhide, as this is still not solved. However, this upstream thread points to a possible solution to letting the user provide XML to override libvirt's default desire to label a particular disk, allowing the user to leave the public_content_t label untouched (if they also added the policy to allow svirt_t to access public_content_t): https://www.redhat.com/archives/libvir-list/2011-December/msg00297.html svirt_t is allowed to read public content in F16 and Rawhide. Additionally, libvirt 0.9.9 allows per-disk overrides (which can be used to avoid relabeling): commit 6cb4acce8b136e0dd2afa647b9b8cdf7c1702aed Author: Eric Blake <eblake> Date: Thu Dec 22 17:47:49 2011 -0700 seclabel: extend XML to allow per-disk label overrides When doing security relabeling, there are cases where a per-file override might be appropriate. For example, with a static label and relabeling, it might be appropriate to skip relabeling on a particular disk, where the backing file lives on NFS that lacks the ability to track labeling. Or with dynamic labeling, it might be appropriate to use a custom (non-dynamic) label for a disk specifically intended to be shared across domains. The new XML resembles the top-level <seclabel>, but with fewer options (basically relabel='no', or <label>text</label>): <domain ...> ... <devices> <disk type='file' device='disk'> <source file='/path/to/image1'> <seclabel relabel='no'/> <!-- override for just this disk --> ... </disk> <disk type='file' device='disk'> <source file='/path/to/image1'> <seclabel relabel='yes'> <!-- override for just this disk --> <label>system_u:object_r:shared_content_t:s0</label> </seclabel> </source> ... </disk> ... </devices> <seclabel type='dynamic' model='selinux'> <baselabel>text</baselabel> <!-- used for all devices without override --> </seclabel> </domain> I'm closing this bug. |