Re: [Qemu-devel] live snapshot wiki updated

[Cleber Rosa <crosa@redhat.com>]

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
>