Messages in this thread | | | Date | Tue, 16 Mar 2010 13:06:42 -0500 | From | Anthony Liguori <> | Subject | Re: [PATCH] Enhance perf to collect KVM guest os statistics from host side |
| |
On 03/16/2010 12:52 PM, Ingo Molnar wrote: > * Anthony Liguori<aliguori@linux.vnet.ibm.com> wrote: > > >> On 03/16/2010 10:52 AM, Ingo Molnar wrote: >> >>> You are quite mistaken: KVM isnt really a 'random unprivileged application' in >>> this context, it is clearly an extension of system/kernel services. >>> >>> ( Which can be seen from the simple fact that what started the discussion was >>> 'how do we get /proc/kallsyms from the guest'. I.e. an extension of the >>> existing host-space /proc/kallsyms was desired. ) >>> >> Random tools (like perf) should not be able to do what you describe. It's a >> security nightmare. >> > A security nightmare exactly how? Mind to go into details as i dont understand > your point. >
Assume you're using SELinux to implement mandatory access control. How do you label this file system?
Generally speaking, we don't know the difference between /proc/kallsyms vs. /dev/mem if we do generic passthrough. While it might be safe to have a relaxed label of kallsyms (since it's read only), it's clearly not safe to do that for /dev/mem, /etc/shadow, or any file containing sensitive information.
Rather, we ought to expose a higher level interface that we have more confidence in with respect to understanding the ramifications of exposing that guest data.
>> >> No way. The guest has sensitive data and exposing it widely on the host is >> a bad thing to do. [...] >> > Firstly, you are putting words into my mouth, as i said nothing about > 'exposing it widely'. I suggest exposing it under the privileges of whoever > has access to the guest image. >
That doesn't work as nicely with SELinux.
It's completely reasonable to have a user that can interact in a read only mode with a VM via libvirt but cannot read the guest's disk images or the guest's memory contents.
> Secondly, regarding confidentiality, and this is guest security 101: whoever > can access the image on the host _already_ has access to all the guest data! > > A Linux image can generally be loopback mounted straight away: > > losetup -o 32256 /dev/loop0 ./guest-image.img > mount -o ro /dev/loop0 /mnt-guest > > (Or, if you are an unprivileged user who cannot mount, it can be read via ext2 > tools.) > > There's nothing the guest can do about that. The host is in total control of > guest image data for heaven's sake! >
It's not that simple in a MAC environment.
Regards,
Anthony Liguori
> All i'm suggesting is to make what is already possible more convenient. > > Ingo >
| |