On Wed, Feb 04, 2015 at 06:05:16PM +0100, Philipp Marek wrote:
> > > > (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.
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.
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 :|
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
