Open Stack

On Fri, Jun 24, 2016 at 11:12:27AM +0200, Thierry Carrez wrote:
> Angus Lees wrote:
> > [...]
> > None of these are great, but:
> > 
> > Possibility 1:  Backdoor rootwrap
> > 
> > However if we assume rootwrap already exists then we _could_ rollout a
> > new version of oslo.rootwrap that contains a backdoor that allows
> > privsep-helper to be run as root for any context, without the need to
> > install a new rootwrap filter.
> > 
> > Disclaimers:
> > 
> > - It wouldn't work for virtualenvs, because the "privsep-helper"
> > executable won't be in sudo's usual PATH.
> > 
> > - Retro-fitting something like that to rootwrap feels like it's skirting
> > close to some sort of ethical contract we've made with admins regarding
> > rootwrap's featureset.  Not saying we shouldn't do it, just that we
> > should think about how an operator is going to feel about that.
> > 
> > 
> > Possibility 2: Wider rootwrap filter
> > 
> > In the past, I've been proposing rootwrap filters that match only
> > specific privsep "privileged contexts" by name.  On further reflection,
> > if we're assuming the existing python modules installed into root's
> > python path are already trustworthy (and we _are_ assuming that), then
> > it might also be reasonable to trust *any* privsep entrypoint declared
> > within that module path.  This gives a larger attack surface to think
> > about (particularly if python libraries including privsep decorators
> > were installed for some reason other than providing privsep entry
> > points), but there's no reason why this is _necessarily_ an issue.
> > 
> > This allows us to get to a single rootwrap filter per-project (or
> > rather, "per-rootwrap") since projects use separate rootwrap config
> > directories - so we would still have to do a thing once per project.
> > 
> > 
> > Possibility 3: Skip rootwrap, use just sudo
> > 
> > sudoers isn't very expressive - but we could install a new rootwrap-like
> > wrapper into sudoers once system-wide, which includes some sort of logic
> > to start privsep-helpers.  This could be as simple as a small shell
> > script.  The advantage this has over rootwrap is that it would contain
> > some sort of system-wide config, rather than per-project.
> > 
> > Downsides
> > 
> > - Would still need to be installed once system-wide.
> > 
> > - Would need to be configured per-virtualenv, since otherwise we have no
> > way to know which virtualenvs should be given root powers.
> > 
> > 
> > Possibility 4: Run as root initially
> > 
> > Another option would be to follow the usual Unix daemon model: Start the
> > process with all required privileges, and avoid sudo/rootwrap entirely.
> > 
> > In this version, we take a once-off hit to tell everyone to start
> > running their OpenStack agents as root (probably from init/systemd), and
> > right at the top of main() we fork() the privsep-helper and then drop to
> > a regular uid.  No sudo or rootwrap ever (although the unprivileged code
> > could continue to use it while we clean up all the legacy code).
> > 
> > A glorious future, but still a big per-project deployment change that
> > has to be managed somehow.
> 
> I'm adding Possibility (0): change Grenade so that rootwrap filters from N+1
> are put in place before you upgrade.
> 
> No perfect answer here... I'm hesitating between (0), (1) and (4). (4) is
> IMHO the right solution, but it's a larger change for downstream. (1) is a
> bit of a hack, where we basically hardcode in rootwrap that it's being
> transitioned to privsep. That's fine, but only if we get rid of rootwrap
> soon. So only if we have a plan for (4) anyway. Option (0) is a bit of a
> hard sell for upgrade procedures -- if we need to take a hit in that area,
> let's do (4) directly...
> 
> In summary, I think the choice is between (1)+(4) and doing (4) directly.
> How doable is (4) in the timeframe we have ? Do we all agree that (4) is the
> endgame ?

We've already merged change to privsep to allow nova/cinder/etc to
initialize the default helper command to use rootwrap:

  https://github.com/openstack/oslo.privsep/commit/9bf606327d156de52c9418d5784cd7f29e243487

So we just need new release of privsep & add code to nova to initialize
it and we're sorted.

We can also revert the changes we made to devstack to update nova.conf
for privsep too.

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