From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36425) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjadG-0008Nz-Lm for qemu-devel@nongnu.org; Wed, 20 Jul 2011 13:32:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjadE-0005yX-OD for qemu-devel@nongnu.org; Wed, 20 Jul 2011 13:32:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32138) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjadE-0005y8-3e for qemu-devel@nongnu.org; Wed, 20 Jul 2011 13:32:24 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p6KHWNK6014564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 20 Jul 2011 13:32:23 -0400 Message-ID: <4E271FAF.1050007@redhat.com> Date: Wed, 20 Jul 2011 14:34:23 -0400 From: Cleber Rosa MIME-Version: 1.0 References: <4E2055AE.8090107@redhat.com> <4E253136.4080509@redhat.com> <4E258635.2040108@redhat.com> <4E258D70.6000205@redhat.com> <4E25902D.2000403@redhat.com> <4E2593B0.1030508@redhat.com> <4E2594FB.4050203@redhat.com> <4E25AD51.4000802@codemonkey.ws> <4E26DD43.2050306@redhat.com> <4E26E764.80809@codemonkey.ws> In-Reply-To: <4E26E764.80809@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] live snapshot wiki updated List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 07/20/2011 10:34 AM, Anthony Liguori wrote: > On 07/20/2011 08:50 AM, Cleber Rosa wrote: >> Just as a reminder: with DAC, if a guest is compromised and somehow >> escalates to QEMU, it could disable its isolation (ie, by setting their >> own image files world readable). I guess we shouldn't try to fix the DAC >> model, but fix what's preventing us from fully using MAC, even though >> it's outside of QEMU. > > I don't see how a guest making its data world readable is a > fundamental problem. Well, if we're discussing security models and how to provide the best isolation we can to VMs/QEMU instances, then a VM being able to read (or even write) data of another VM *is* a fundamental problem. "setting their own imagine files world readable" is just one example of how that could be accomplished. > > DAC is a fundamental part of the Unix design and is something that > administrators understand very well. That's is a true sentence, but it does not make DAC the most appropriate solution here. > I completely understand the value of MAC but to argue that we > shouldn't present DAC as an option I think is fundamentally wrong. I never said, and really don't think we shouldn't provide other security options/models, this is actually part of the well accepted "security in multiple layers" strategy. I did assume, though, we were aiming for the best isolation level, and that is definitely MAC. DAC may indeed be good enough for some, but definitely not good enough for many others. CR. > > Regards, > > Anthony Liguori > >> >> CR. >> >>> >>> Regards, >>> >>> Anthony Liguori >>> >> >> > >