Stefan Hajnoczi <stefa...@gmail.com> writes: > On Fri, Jun 18, 2010 at 8:27 AM, Markus Armbruster <arm...@redhat.com> wrote: >> Stefan Hajnoczi <stefa...@gmail.com> writes: >>> On Thu, Jun 17, 2010 at 1:49 PM, Markus Armbruster <arm...@redhat.com> >>> wrote: >>>> Stefan Hajnoczi <stefa...@gmail.com> writes: >>>>> On Wed, Jun 16, 2010 at 6:27 PM, Markus Armbruster <arm...@redhat.com> >>>>> wrote: >>>> To let users ask for this explicitely, we could have pseudo-format >>>> "auto". >>>> >>>> We also need a pseudo-format "probe", which guesses the format from the >>>> image contents. Can't be made the default, because it's insecure. >>> >>> In which scenario is probing the image format a security issue? I'm >>> trying to think up scenarios where a cloud user modifies the guest >>> disk image and gets QEMU to re-open the image file as another format, >>> perhaps this would make the cloud owner/admin unhappy. I don't see a >>> threat except for image format drivers have security bugs (corrupt >>> images leading to arbitrary code execution). >> >> User creates a raw image file. >> >> VM starts. Image file gets probed, it's raw. Guest has access to the >> complete file. >> >> Guest writes a valid QCOW2 image to it, chosen to include the full >> backing file in the resulting image contents. Set the backing file to >> /secret/treasure. >> >> Reboot VM. Image file gets probed, it's qcow2. Backing file gets >> probed, it's raw. Guest has access to the contents of QCOW2 image. >> This includes the backing file. Oops. > > I thought selinux/svirt was supposed to secure QEMU processes and > ensure they only have access to the resources they need? If the > backing file doesn't belong to me then my QEMU process shouldn't be > able to open it.
Yes, SELinux will protect you from security holes in applications. Protecting from != fixing of :)
