Open Stack

On Wed, Feb 04, 2015 at 05:52:12PM +0100, Philipp Marek wrote:
> Here are my 2¢.
> 
> > > >> (1) we could get our act together and audit and fix those filter
> > > >> definitions. Remove superfluous usage of root rights, make use of
> > > >> advanced filters for where we actually need them. We have been preaching
> > > >> for that at many many design summits. This is a lot of work though...
> > > >> There were such efforts in the past, but they were never completed for
> > > >> some types of nodes. Worse, the bad filter definitions kept coming back,
> > > >> since developers take shortcuts, reviewers may not have sufficient
> > > >> security awareness to detect crappy filter definitions, and I don't
> > > >> think we can design a gate test that would have such awareness.
> Sounds like a lot of work... ongoing, too.
> 
> 
> > > >> (2) bite the bullet and accept that some types of nodes actually need
> > > >> root rights for so many different things, they should just run as root
> > > >> anyway. I know a few distributions which won't be very pleased by such a
> > > >> prospect, but that would be a more honest approach (rather than claiming
> > > >> we provide efficient isolation when we really don't). An added benefit
> > > >> is that we could replace a number of shell calls by Python code, which
> > > >> would simplify the code and increase performance.
> Practical, but unsafe.
> 
> I'd very much like to have some best-effort filter against bugs in my 
> programming - even more so during development.
> 
> 
> > (4) I think that ultimately we need to ditch rootwrap and provide a proper
> > privilege separated, formal RPC mechanism for each project.
> ...
> > we should have a  nova-compute-worker daemon running as root, that accepts
> > an RPC command from nova-compute running unprivileged. eg
> >
> >     CreateImage("instane0001", "qcow2", "disk.qcow")
> ...
> > This is certainly alot more work than trying to patchup rootwrap, but
> > it would provide a level of security that rootwrap can never achieve IMHO.
> A lot of work, and if input sanitation didn't work in one piece of code, 
> why should it here?
> 
> I think this only leads to _more_ work, without any real benefit.
> If we can't get the filters right the first round, we won't make it here 
> either.

The difference is that the API I illustrate here has *semantic* context
about the operation. In the API example the caller is not permitted to
provide a directory path - only the name of the instance and the name
of the disk image. The privileged nova-compute-worker program can thus
enforce exactly what directory the image is created in, and ensure it
doesn't clash with a disk image from another VM.  This kind of validation
is impractical when you are just given a 'qemu-img' command line args
with a full directory path, so there is no semantic conext for the privileged
rootwrap to know whether it is reasonable to create the disk image in that
particular location.

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 :|