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

[Anthony Liguori]

On 03/16/2010 12:52 PM, Ingo Molnar wrote:
> * Anthony Liguori<aliguori@xxxxxxxxxxxxxxxxxx>  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
>    

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/