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