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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B9FC8B2.6070404@linux.vnet.ibm.com>
Date:	Tue, 16 Mar 2010 13:06:42 -0500
From:	Anthony Liguori <aliguori@...ux.vnet.ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	"Frank Ch. Eigler" <fche@...hat.com>, Avi Kivity <avi@...hat.com>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	oerg Roedel <joro@...tes.org>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.com
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@...ux.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
>    

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