Re: [libvirt] RFC: Limited dynamic ownership
On Tue, Aug 23, 2016 at 05:06:20PM -0400, Martin Kletzander wrote:
Hi everyone,
so there was an idea about limiting the relabelling of images that
libvirt does. And I'm taking the liberty of pitching my idea how to
approach this. I feel like it's pretty simple thing and there's not
much to talk about, but a) I could've missed something and b) you might
hate the way I approach it.
The idea is to extend the seclabel XML, for example:
<seclabel type='dynamic' model='dac' relabel='whitelist'>
<path>/var/lib/libvirt/images</path>
<path>/data/virt-stuff</path>
</seclabel>
Either we allow 'relabel' to be set to 'whitelist' or add a new
attribute with a name like 'mode' or something, which will control how
we relabel the files (actually relabel='no' can mean 'whitelist' and
relabel='yes' can mean blacklist without adding anything there). After
that you can specify what paths are (dis)allowed to be labelled.
Actually thinking about it I like the following the most:
<seclabel type='dynamic' model='dac' relabel='no'>
<whitelist path='/data'/>
<blacklist path='/data/private/non-virt/stuff'/>
</seclabel>
which I believe is pretty explanatory. Feel free to ask if it's not.
And let me know what you think.
I don't think we need to get involved in the <seclabel> configuration.
We've already got the ability in the <disk> config to provide the
full backing chain explicitly. If a management app provides a full
backing chain in the XML, we could validate the app provided chain
against the chain we probe and report error if they mis-match. (Maybe
we in fact already report this?)
Thinking bout this in the context of a recent OpenStack Nova CVE,
where Nova mistakenly set format=qcow2, instead of format=raw, allowing
a malicious guest to write a qcow2 header with backing file. If Nova
had provided the full backing chain it expected (no backing chain at
all), then libvirt would have seen the maliciously created backing
chain, and caught the problem despite Nova giving the wrong format.
Separately from this, in the context of storage pools, when giving
a <disk type=pool> in the domain XML, we could do validation to
ensure the backing file of the volume always pointed to a volume
that was also inside a storage pool. This would allow us to have
backing files pointing to volumes in different storage pools, but
would prevent them pointing to arbitrary files that were not in
storage pools at all (eg /etc/password, or /dev/root, etc).
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 :|