Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism

[Daniel P. Berrange]

On Mon, Oct 03, 2016 at 03:41:10PM -0000, Rafael David Tinoco wrote:
> Sorry, I was only able to come back to this today.
> 
> > On Sep 27, 2016, at 09:18, Daniel Berrange <address@hidden> wrote:
> > 
> >> There are numerous people relying on older kernels in openstack 
> >> deployments - sometimes with specific drivers (ovswitch, dpdk, 
> >> infiniband) holding kernel upgrades - but still in need of upgrading 
> >> userland (e.g. newer releases). Having a fallback mechanism seems 
> >> appropriate for those cases.
> > 
> > I'm not against some kind of fallback - just about the way it
> > silently creates files in /tmp.
> > 
> 
> That is why memfd_create is used here I suppose: To allow anonymous-
> backed-pages to have a descriptor and to be sealed. When falling back
> this mechanism I don't see any other way other than creating a temporary
> file. Of course one way would be something like:
> 
> http://paste.ubuntu.com/23270379/
> 
> But this is pretty much the same, just solving the "where to place the
> temporary file" (non configurable for this usage).
> 
> >> 
> >> Note that the filename, per se, is not as important as other files, 
> >> since qemu won't provide it for being accessed by external programs, and,
> >> deletes the file, while keeping the descriptor, right after its creation
> >> (due to its nature, that is probably why it was created in /tmp).
> > 
> > If it doesn't shared with other processes, and is deleted immediately,
> > why does the file need to be on disk at all ?
> 
> Well, it unlinks the file but the references are still there while the
> descriptor isn't closed by this process, or by the one that receives the
> descriptor (that is why is the "unlink" so early).
> 
> If you check vhost_dev_log_resize(), it gets *possible* new vhost log
> (if a new size is given) and informs the vhost dev driver about the new
> log base (vhost_ops->vhost_set_log_base).
> 
> For vhost_user, this means that the file descriptors for vhost logs are
> likely going to be passed to vhost backend (fds[] in
> vhost_user_set_log_base). This is just one example, not sure about
> others.
>
> Probably the best approach here, like what Marc-André said, is to create
> some sort of TMPDIR, set by libvirt perhaps ?

So you're saying that the file descriptor here is actually getting
passed to a different process for it to use ?

If so that means we definitely do not want this in TMPDIR. If we
create a generic file in TMPDIR, then its going to have a generic
security label. That means that the other process we're giving the
FD to is going to have to be granted permission to access this FD
and we certainly don't want to grant permission for it to access
any of QEMU's other FDs. So for the SELinux integration, we'll
need this FD to be in a specific directory, so that we can setup
policy such that the file created gets given a specific SELinux
label. We can then grant the other process access to only that
particular file, and not anything else of QEMU's.

This makes me wonder about the memfd_create() code path too - we'll
again not want that external process to be granted access to arbitrary
FDs of QEMU's and I'm not sure of a way to get the memfd  FD to have
a specific label. So I think it is possible that when using libvirt
we'll want the ability to tell QEMU to *always* use an explicit file
in a path libvirt specifies, and never use memfd even if available.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|