[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] util: secure memfd_create fallback mechanism
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] [PATCH] util: secure memfd_create fallback mechanism |
Date: |
Tue, 27 Sep 2016 09:36:26 +0100 |
User-agent: |
Mutt/1.7.0 (2016-08-17) |
On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote:
> Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback
> mechanism for systems not supporting memfd_create syscall (started
> being supported since 3.17).
This is really dubious code in general and IMHO should just
be reverted.
We have a golden rule that any time QEMU needs to be able to
create a file on disk, then the path should be explicitly
provided as a command line argument so that mgmt apps can
control the location used.
> Backporting memfd_create might not be accepted for distros relying
> on older kernels. Nowadays there is no way for security driver
> to discover memfd filename to be created: <tmpdir>/memfd-XXXXXX.
>
> It is more appropriate to include UUID and/or VM names in the
> temporary filename, allowing security driver rules to be applied
> while maintaining the required unpredictability with mkstemp.
We should not have QEMU creating unpredictabile filenames in the
first place - any filenames should be determined by libvirt
explicitly.
> This change will allow libvirt to know exact memfd file to be created
> for vhost log AND to create appropriate security rules to allow access
> per instance (instead of a opened rule like <tmpdir>/memfd-*).
Even with this change it is bad - we don't want driver backends
creating arbitrary files in the shared /tmp directory.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|