From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41950) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjWD1-0005GU-Qb for qemu-devel@nongnu.org; Wed, 20 Jul 2011 08:49:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjWCz-0001CX-II for qemu-devel@nongnu.org; Wed, 20 Jul 2011 08:49:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55635) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjWCz-0001CL-1m for qemu-devel@nongnu.org; Wed, 20 Jul 2011 08:49:01 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p6KCmxWa029930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 20 Jul 2011 08:48:59 -0400 Message-ID: <4E26DD43.2050306@redhat.com> Date: Wed, 20 Jul 2011 09:50:59 -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> In-Reply-To: <4E25AD51.4000802@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/19/2011 12:14 PM, Anthony Liguori wrote: > On 07/19/2011 09:30 AM, Jes Sorensen wrote: >> On 07/19/11 16:24, Eric Blake wrote: >>> [adding the libvir-list] >>> On 07/19/2011 08:09 AM, Jes Sorensen wrote: >>>> Urgh, libvirt parsing image files is really unfortunate, it really >>>> doesn't give me warm fuzzy feelings :( libvirt really should not know >>>> about internals of image formats. >>> >>> But even if you add new features to qemu to avoid needing this in the >>> future, it doesn't change the past - libvirt will always have to know >>> how to parse image files understood by older qemu, and so as long as >>> libvirt already knows how to do that parsing, we might as well take >>> advantage of it. >> >> What has been done here in the past is plain wrong. Continuing to do it >> isn't the right thing to do here. >> >>> Besides, I feel that having a well-documented file format, so that >>> independent applications can both parse the same file with the same >>> semantics by obeying the file format specification, is a good design >>> goal. >> >> We all know that documentation is rarely uptodate, new features may not >> get added and libvirt will never be able to keep up. The driver for a >> file format belongs in QEMU and nowhere else. >> >> >>>>> It would be nice if libvirt had a way to pass fds for every disk and >>>>> backing file up front; then, SELinux can work around the lack of NFS >>>>> per-file labelling by blocking open() in qemu. In fact, this has >>>>> already been proposed: >>>> >>>> A cleaner solution seems to have libvirt provide a call-back allowing >>>> QEMU to call out and have libvirt open a file descriptor instead. This >>>> way libvirt can validate it and open it for QEMU and pass it back. >>> >>> Yes, that could probably be made to work with libvirt. >> >> I am a little frustrated this approach wasn't taken up front instead of >> the evil hack of having libvirt attempt to parse image files. >> >>>> If we cannot do something like this, I would prefer to have backing >>>> files on NFS should simply not be supported when running in an selinux >>>> setup. >>> >>> As nice as that sentiment is, it will never fly, because it would be a >>> regression in current behavior. The whole reason that the virt_use_nfs >>> SELinux bool exists is that some people are willing to make the partial >>> security tradeoff. Besides, the use of sVirt via SELinux is more than >>> just open() protection - while the current virt_use_nfs bool makes NFS >>> less secure than otherwise possible, it still gives some nice >>> guarantees >>> to the rest of the qemu process such as passthrough accesses to local >>> pci devices. >> >> Well leaving things at status quo is not making it worse, it just leaves >> an evil in place. > > NFS and SELinux is a fundamental problem with SELinux and NFS. We can > piss and moan as much as we want about it but it's reality. SELinux > fundamentally requires extended attributes. By the time NFS adds > extended attribute support, we'll all be flying around in hover cars. > > As terrible as NFS is, people use it all of the time. > > It would be nice if libvirt had the ability to make better use of DAC > to support isolation. The fact that MAC is the only way you can do > isolation between guests is pretty unfortunate. If I could assign > specific UIDs to a guest and use that to enforce isolation, it would > go a long ways to solving this problem. 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. CR. > > Regards, > > Anthony Liguori >