On 07/21/11 10:36, Kevin Wolf wrote:
Am 21.07.2011 10:07, schrieb Jes Sorensen:
> Rather than trying to do this by mangling files on the disk, I would
> suggest we allow registering a call-back open function, which calls back
> into libvirt and requests it to open a given file. It can then do all
> it's security foo to decide whether or not to allow the file to be open.
>
> This is relatively clean and avoids the mess of relying on outside
> processes messing about in the images.
You forget that libvirt parses images exactly to decide whether to allow
accesses or not, so they would still do it. Which shouldn't be a big
problem anyway as long as the libvirt implementation is compliant to the
image format specification (even though it's not nice, of course).
As I just responded to Daniel, this doesn't make sense. If libvirt wants
to guard against a compromised QEMU, it cannot rely on things written
into image files headers by QEMU.
If we trust contents of image files, there is no reason not to grant
QEMU full access to files on NFS either, as we have effectively already
granted that by trusting the image file content.
In other words, if the goal is to make this secure, lets make it secure,
otherwise, lets stop pretending.
I just wonder why libvirt doesn't trust qemu enough that it can
open()
what it wants, but at the same time relies for this check on information
in image files which this very same qemu can modify.
Probably for the same reason few QEMU developers trust libvirt....
Jes