strawman - make the agents not run as root

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-12-17 7:39, Tim Penhey wrote:
> Hi folks,
> 
> We have been telling people for ever not to run things as root.
> Most packages that run systems things create users for that
> purpose.
> 
> Every time I think of our machine and unit agents running as root,
> I end up feeling a little guilty. Why is this fine for us?
> 
> However, we can't just make a change and expect everything to
> work.
> 
> Firstly there are the charms, they expect "apt-get install" to
> work, and if we change our user, it won't.
> 
> A suggestion would be to make an option for environment to use
> non-root users for the agents, and default it to false.  This would
> allow us to create environments where we do have non-root users and
> at least make sure all our stuff works.
> 
> Then we could move to a QA mode where all charms get tested to make
> sure that for any privileged action, it uses 'sudo'.  This gives
> us privileged action logging.
> 
> What are your thoughts?
> 
> Tim
> 

I think trying to figure out what we actually win/lose with this is
worthwhile

1) If not running as root we 'win' that a rogue Jujud process (and the
hooks it executes) can't do arbitrary things to your system.

2) We lose the fact that hooks can't do arbitrary things to your
system. Sort of the *point* of what Juju hooks are is the equivalent
of a system admin going around and fixing up config files for various
services on your system. So you might need to create the 'apache'
user, or edit the 'apache' user's files, or maybe it is the 'postgres'
user's files, or etc.

So I think we *could* have the jujud process itself not run as root,
but all of the hooks that it fires need to have root level priviledges
because pretty much by definition they are doing root-level operations.


Now, we could certainly request that charms be written to distinguish
things that actually need to have root level priviledge (rewriting the
postgres's db.conf file) from things that don't (echo $foo | sed blah
| etc).

I agree that having 'sudo' lines would make it easier to audit the
charm by visual inspection. So more than that things are in the 'sudo'
log, they are just visually distinct in the hook source.

So while I don't think it directly improves security, because
everything we run needs to have the ability to escalate to root level,
it might make it easier to write those things in a sane fashion.

That said, it breaks everything we have today, so we'd need some sort
of a flag on a charm that says it supports running in sudo mode. We
could migrate in that direction if we started by getting 'jujud'
itself to just run 'sudo hook' if the charm didn't support it, and
then just 'hook' if it does.

Until the actual catalog of charms actually supported it, we wouldn't
have benefited anyone, though. So I think it is worth thinking about,
but we have bigger things on the table to get done first.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKv7dkACgkQJdeBCYSNAAPx1ACdHbYLcGPg/D3rrFq8W1AJ9+go
OLEAnAxX81HX4sIktNSCAy/P5SHVegwC
=aSHR
-----END PGP SIGNATURE-----