Re: [PATCH] Enhance perf to collect KVM guest os statistics from host side

[Anthony Liguori <aliguori@linux.vnet.ibm.com>]

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
>