[Nagiosplug-devel] Security discussion - don't run as root plugins

[Thomas Guyot-Sionnest]

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

On 19/07/08 02:16 PM, Hendrik BŠäcker wrote:
> 
> 
> Andreas Ericsson schrieb:
> | Thomas Guyot-Sionnest wrote:
> |> At the same time we would need a standard option to specify a user to
> |> run as, so that anyone requiring root (or any other user) privileges for
> |> some reason would still be able to.
> |>
> |
> | I'd hate that idea, since all plugins would need to be suid root for this
> | to actually work if the user running them is anyone else than root or
> | is already the user supposed to run the plugin. It's stupid. Don't do it.
> |
> I'm with Andreas. If the Mainstream decide to do s.th. against the lazy
> unsecure people to make it harder to compromise security - you won't
> have a config line easily set to "run_as = root".
> 
> Users have to do s.th. special to let them run as root. If they had to
> think about and decide anyway against security it's ok. You can be sure
> that they do it with knowledge of the risk.

I think I may have been a bit unclear. I really don't want any more
plugins running as root/suid (I think there's only check_icmp and
check_dhcp for now). What I'm suggesting is making it the default
behaviour to drop root privileges if run as root.

Plugins would still be installed as they are (no suid unless absolutely
required) and we would still recommend to run plugins as an unprivileged
user. However if under any circumstance (check_by_ssh, nrpe running as
root, cronjob, etc.) a plugin starts as root it would drop privileges
before doing anything else.

So I'm viewing this as an additional security mechanism. The "standard"
switch to specify a user/uid I'm talking about would primarily be a
"disable" switch. If someones wants - for any reason - to run a plugin
as root that's _his_ problem and I can't do anything against it. At the
same time it could be used to specify a user for anyone too lazy to set
it up in a better way (still better IMHO that just running as root!).

> A next possible step could be to drop privileges or deny a plugin run if
> uid is zero - except that the user on the other side has to do it explicit.
> I could imagine of a getopt optione like "--yes-run-as-root" without a
> shortcut like "-r" for it. If the user has to type this into his command
> definition he should know that he is doing.

That's where I don't agree. Why denying when you can just drop
privileges by default? And anyone that still want to sun as root would:

1. setuid/run the plugin as root
2. Use the switch I mentioned above to force UID 0

No non-root plugin would run as root without the user knowing about it.


One more though about it... I talked about a switch so far, but I think
it could be a better idea to make it an environment variable, so we
could drop root even before parsing arguments. Bugs in argument
processing could become a security issue if untrusted users has the
possibility to specify/alter arguments. While I'm aware there are many
other security implication regarding this, it's not a reason not to do
our best on the part we control.


Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIgkIr6dZ+Kt5BchYRAiKsAJ9czU7+tIxGAnWvjrScXYjYce0eJACgoPSh
ysyzV3EMubGA6WPz5gOeiGA=
=g63d
-----END PGP SIGNATURE-----