Open Stack

Hi Daniel,

> > 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.
> 
> No, that is really not correct. If you are passing full command strings to
> rootwrap then the caller can trick rootwrap into running commands with those
> shell metacharacter exploits.  If you have a formal API like the one I describe
> and correctly implement it, there would be no shell involved at all. ie the
> nova-compute-worker program would directly invoke the system call
> 
>    execve("/usr/bin/qemu-img", "create", "image.img & rm -rf /")
> 
> and this would at worse create a file called  'image.img & rm -rf /' and
> *not* invoke the "rm" command as you get when you use shell.
> 
> This is really just another example of why rootwrap/sudo as a concept is a
> bad idea. The shell should never be involved in executing any external
> commands that Nova/Neutron/etc need to run, because it is impractical to
> correctly validate shell commands anywhere in the stack. The only safe
> thing todo is to take shell out of the picture entirely.
that was just an example.

If cinder calls rootwrap with a list of arguments, and this is then called 
via sudo, there's no shell inbetween either.


But now say there's something else, like the bash functions bug, and 
some codepath runs a command in a way that sets the environment - then any 
grandchild processes might cause a breach.


I'm not arguing that *this exact string* is a problem.
My point is that the cinder/nova code already have as much information as 
possible, and *any* library abstraction can just remove some available 
data.
So, besides increasing the LOC, it won't get more secure.


I'm arguing that the rootwrap call sites need to be fixed, ie. they need to 
"proof" in some way that the arguments they pass on are sane - that's more 
or less the same thing that this new library would need to do too.



Regards,

Phil

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