Integrate nagios users with system ones

[karaluh]

Binary package hint: nagios3

According to the documentation https://help.ubuntu.com/community/Nagios3 there's aditional postinstalation step required to create user to acces the web interface. Nagios should accept system credentials instead.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: nagios3 3.2.0-4ubuntu2
ProcVersionSignature: Ubuntu 2.6.32-20.30-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-20-generic i686
Architecture: i386
Date: Tue Apr 13 10:56:04 2010
ProcEnviron:
 LANGUAGE=pl_PL:pl:en_GB:en
 PATH=(custom, no user)
 LANG=pl_PL.UTF-8
 SHELL=/bin/bash
SourcePackage: nagios3

[Jan Wagner (waja)]

Do you guys really think, that using system users would be a good idea? Do you like to login to the nagios webinterface as root?

[karaluh (karaluh)]

root is disabled by default. The thing that I realy don't like is creating users for every software I use.

[Jan Wagner (waja)]

Sorry ... using system users within nagios is in my eyes a security problem, but maybe I'm wrong.

Jan, with his debian nagios maintainers hat on.

[Rhonda D'Vine (rhonda)]

We had a short discussion and Alexander Wirt raised a very important part:

Enabling the webinterface to authenticate against system users would technicly mean that one would have to enable the webserver to read the shadow file. The shadow file is readable only by root on intention and opening that to the www-data user is asking for way more troubles than it would solve.

Please try to understand that this won't happen

[Piotr Skamruk (jell)]

Why www-data would have to read shadow file?
What about using pam modules?
With that - authentication could use not only local user database, but also ldap, or either mechanism...

karaluh - better place to ask about such thinks would be nagios mail list, so you should start looking closer to sources ;)

[Alexander Wirt (formorer)]

Speaking with my nagios3 maintainer in debian hat on

> Why www-data would have to read shadow file?
> What about using pam modules?
even libpam needs access to the password hashes. Just by using libpam you don't get magically access to them.
Citing from libapache2-mod-auth-pam package:
  To use with standard Debian configuration you have to add "www-data" user to
  "shadow" group. Be careful! It means it can be readable by anyone who can run
  its own CGI script!

> With that - authentication could use not only local user database, but also ldap, or either mechanism...
The bug is talking about default setups and giving www-data access to shadow is really part for nightmares.

So speaking for Debian, this will never happen. And if Ubuntu adds this by default they are are creating a big security problem. In times of rainbow tables password hashes are not really secure.

And looking the nagios sources is stupid. Using apache auth is the most flexible way Nagios can go and I doubt that any of the Nagios devs will change this for Nagios-Core.

[Piotr Skamruk (jell)]

I was sure that libpam to acces shadow uses some suid helper program.
So i was wrong about it...

[James Y Knight (foom)]

You want to be using saslauthd and apache's mod-authn-sasl. Then you don't need to give httpd access to /etc/shadow.

[Alexander Wirt (formorer)]

sure, or you can use LDAP, *SQL or whatever for auth - but there is no sensible default.

[Philipp Kern (pkern)]

> I was sure that libpam to acces shadow uses some suid helper program.
> So i was wrong about it...

There is a suid helper program in pam_unix, called unix_chkpwd. But for obvious reasons it only allows to check the password of the current user, which is in turn used by programs like gnome-screensaver to verify the password. It does not work for brute-forcing or checking any other user's password.