Open Stack

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.


Regarding the idea of using containers ... take Cinder as an example.
If the cinder container can access *all* the VM data, why should someone 
bother to get *out* of the container? Everything that she wants is already 
here...
I'm not sure what the containers would buy us, but perhaps I just don't 
understand something here.


So, IMO, solution 1 (one) would be the way to go ... it gets to security 
asymptotically (and might never reach it), but at least it provides a bit 
of help.

And if the rootwrap filter specification would be linked to in the rootwrap 
config files, it would help newcomers to see the available syntax, instead 
of simply copying a bad example ;P



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