Jes Sorensen <Jes.Sorensen@xxxxxxxxxx> writes:
> On 07/19/11 18:14, Anthony Liguori wrote:
>>>> 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.
>
> Right, we're stuck with the two horros of NFS and selinux, so we need
> something that gets around the problem. In a sane world we would simply
> say 'no NFS, no selinux', but as you say that will never happen.
>
> My suggestion of a callback mechanism where libvirt registers the
> callback with QEMU for open() calls, allowing libvirt to perform the
> open and return the open file descriptor would get around this problem.
No go, I'm afraid.
The problem at hand is how to confine the untrusted QEMU process so it
can access exactly the resources the guest configuration specifies, no
more, no less.
When guest configuration says "use image A", it really means "file A
plus certain other resources that are required to use it". For obvious
usability reasons, we don't require spelling out "certain other" if we
can safely get the information from A.
Example: file foo.qcow2 requires its backing file file foo.img.
Obviously, the code to get information from A must be trusted.
Therefore, it can't run in the untrusted QEMU process.
Example: the proposed callback mechanism.
Guest configuration says "use image foo.qcow2". Libvirt (or
whatever management layer) arranges that the QEMU process can use
file foo.qcow2.
The QEMU process then uses the callback to gain access to the
backing file. Nothing stops it to ask for whatever file it wants.
How can libvirt decide whether the file is one of the resources the
guest configuration specifies?
The only way I can see around having libvirt read resource information
from images (preferably via a suitable library provided by QEMU) is to
require the administrator to spell out the resouce information.
Administrators generally don't fancy spelling out things the computer
already knows.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list