Open Stack

> > > (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.
Sorry about being unclear.

Yes, there's some semantic meaning at that level. But this level already 
exists at the current rootwrap caller site, too - and if that one can be 
tricked to do something against "image.img & rm -rf /", then the additional 
layer can be tricked, too.


I'm trying to get at the point
  everything that can be forgot to check at the rootwrap call site now,
  can be forgotten in the additional API too.

So let's get the current call sites tight, and we're done.  (Ha!)


-- 
: Ing. Philipp Marek
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting                 http://www.linbit.com :

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.