Open Stack

On Sat Feb 14 2015 at 1:14:09 AM Thierry Carrez <thierry at openstack.org>
wrote:

> Angus Lees wrote:
> > So inspired by the "Rootwrap on root-intensive nodes" thread, I went and
> > wrote a proof-of-concept privsep daemon for
> > neutron: https://review.openstack.org/#/c/155631
>
> Nice work! Trying to check where the security model is actually weaker
> than the one provided by rootwrap here...
>
> If I read this correctly, one of the drawbacks compared to the rootwrap
> approach is that all the functions are accessible on any node running
> the privsep daemon.
>
> When properly packaged, the rootwrap system only has the relevant filter
> definition files present, which dramatically reduces what you allow to
> run as root there. For example, nova-metadata nodes can only run
> iptables to add a firewall rule, since that's the only filter definition
> file shipped on those nodes. That's a benefit of shipping allowed
> commands in the configuration, rather than in the code. With the
> proposed system, the nova-metadata node running with nova-privsep would
> have access to any function defined there, including the rather
> permissive file manipulations that nova-compute needs.
>
> Maybe one way to solve that would be to have several different privsep
> daemons in nova to run on the various types of nodes, each with their
> own set of allowed functions...
>
> Additionally, rootwrap was extremely lean in terms of dependencies --
> basically only allowing Python stdlib module imports to reduce the
> envelope of code you need to trust to run things as root. Here you are
> reusing the Neutron agent framework, which has a pretty long list of
> module imports, which are all imported before the rights are dropped.
> That means you end up blindly trusting a widely larger envelope of modules.
>
> My suggestion would be to not run it as an agent but as a standalone
> daemon with an aggressively-limited set of module imports (ideally only
> stdlib).
>

Yeah, good point - I was assuming we needed to protect against exploits
that might occur after we started processing network events rather than
something that might have already modified root-write-only python library
files before we even started...

At the high level, I feel that interfacing via the relevant syscalls
directly is going to be more reliable and more easily understood (and of
course less overhead) than via command line tools.  This direction
necessarily involves pulling in more libraries to help with that, however.

(Thinking as I type) Hrm, I was going to suggest re-execing the interpreter
at privsep startup, but that can still assumes the python environment is
safe at that point (in which case you've already forked and you may as well
continue in this safe environment - without the exec).  I think an
improvement here requires starting the agent and all its imports as
non-root, and then gaining privileges at the same time as using a fresh
interpreter by starting the privsep daemon via sudo.  That way you only
have to audit for malicious monkey-patching in the code of anything privsep
imports after that point.
This also helps with the migration story (see previous post) and I'll add
it to my todo list.

That's all I could spot with a cursory look :)
>

(Thanks for looking!)

 - Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150216/f5ca58d4/attachment.html>