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

[Hendrik BŠäcker]

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



Andreas Ericsson schrieb:
| Thomas Guyot-Sionnest wrote:
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> On 18/07/08 02:46 PM, Hendrik Bäcker wrote:
|>> Hi List,
|>>
|>> just a few moments ago I've read a question by a user if it would be a
|>> problem to run the nagios plugins with root right via check_by_ssh.
|>>
|>> Yes - I laughed too as I read that. But in the following discussion it
|>> clears up - they already have a spreaded root ssh key on most of their
|>> systems and are to lazy to establish an unprivileged 'nagios' user on
|>> their systems - so they would run them as root.
|>>
|>> I know, security awareness should be part of the persons who are using
|>> the tools, scripts and programs - but 80% of security holes came from
|>> people who didn't know what they are doing.
|>>
|>> Without starting a flame on this topic I would like to ask what do you
|>> think of some security benefits like:
|>>
|>> * don't run the code if UID is 0: Hard but effective - check uid and
|>> abort with a warning.
|>> * try to drop the privileges to the givven user by the configure run as
|>> a hard coded option
|> This is indeed a good idea... I think all plugins could drop privileges
|> if they are run as root. We should probably make it an option for both
|> Perl (Nagios::Plugins) and C plugins, and turn it to default behaviour
|> in a major release.
|>
|
| Sensible. Just do setuid(geteuid()); in C, and whatever's equivalent in
| perl.
|
I think there are only a few lines for this in C, some fewer lines in
perl if someone decide to "use Posix" in any perlplugins - that would be
another dependency for plugins that might not be wanted.

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

|> This could also help catching the typical permission problems where
|> users succeed running plugins as root, but fails running them from
Nagios.
|>
|
| That can already be caught using mechanisms such as sudo. There's no way
| of making bug-reports more accurate by trying to make plugin error
reporting
| fool-proof, so don't even try it. Let's make sure they fail in a
predictable
| way with an accurate error message if they don't have permissions
instead.
|
Full acknowledge.

How many errors do we read all the day as this: "Hey guys, I've tested
the following:

some-system # ./check_logfiles -f /var/log/auth ...

and it ran fine, but if I say nagios to this it doesn't find anything.
Oh wait, something has changed:

nagios at some-system ˜ ./check_logfiles -f /var/log/auth ...
Permission denied.


We all know that there are root needed plugins, and it's ok that there
are some which need such a high privilege level.
I guess these are the typical 80/20 things - 80% of the plugins out
there don't need root, so nearly no one will do a code analysis against
them but on the other side there are 20% of higher skilled users that
will look into the code if it depends on root privileges. These guys
might feeding lists like this if they found a bug that might open a door
to an attacker.

For myself: As I heard that check_icmp needs a setuid(0) I looked into
the code to see that it only needs it for direct network access and so
on - but until today I never looked into check_disk.c if it might tag
some inodes to unaccessible on every run.

The plugin devel team already has done a step. You have to explicit
enter a 'make install-root' for the few plugins.

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.

I guess this is more a political decision as a technical.

Regards,
Hendrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkiCL20ACgkQlI0PwfxLQjldngCeN3qRVi1PXFfxZq0CQfyYF/kG
6bMAoIYBljhb0O/4ZBVJAKINqmmsiRSn
=USAo
-----END PGP SIGNATURE-----