[Pkg-nagios-devel] does it seem feasible to make the icinga/nagios packages users/groups configurable

[Christoph Anton Mitterer]

Hi.

I didn't want to open a wishlist bug immediately but rather ask for
thoughts here now.

With both, icinga and nagios, as well as other befriended stuff (NRPE,
IRPE, icinga-web, PNP4Nagios, etc. pp.) we have many stuff running under
some user and also many files owned by some user/group.

Right now all these user/groups seem to be simply set to a combination
of nagios:nagios www-data:www-data or a mix of these.


Well,... IMHO that could be improved with respect to user-privilege
separation... for all the well known security-related advantages (guess
I don't need to discuss these).

Some simple examples:
1) On could have a system where e.g. both nagios and icinga runs.
Perhaps for different customers. They use the same users/grous and are
therefore more easily attackable in case one of them is successfully
attacked.

2) A system where nagios|icinga && NRPE|IRPE runs... if NRPE|IRPE is
successfully attacked, nagios|icinga are, too.


3) Of specific concern for me personally is the use of www-data.
For security reasons I dislike using apache-mod-php, as everything is
run under the context of the webserver. If just a single PHP suite
hosted on the server in any vhost has a hole... all the others are
likely attackable, too.

Which is why I personally use PHP via CGI,... and run (and really
enforce this) each PHP suite hosted on a server as a different
cgi-something user.
e.g. cgi-phpbb, cgi-icinga (for the classic web), cgi-icinga-web (for
the new web), cgi-davical (a caldav server).

4) Another advantage of this is, that you can easily and securely
separate access permissions to databases in e.g postgresql.
As each web-app runs under it's own user, I simply authenticate via peer
authentication over unix sockets.
No need for (always somehow hackable passwords, that need to be
maintained and configured).


Now quite obvious, most things than don't work with such separation at
first, as access rights are missing.
Right now there are two ways of handling this:
1) Manually setting rights and always doing this again when some update
occurred.
=> annoying but has the advantage that you don't forget any entries in
dpkg-statoverride, in case they should no longer be needed

2) dpkg-statoverride
=> works automatically to some extent, but not when new files are added
that need adjusted permissions
=> you likely forget to remove overrides, in case they should be no
longer needed at some point

3) Problem of all of them:
If more than on program needs access to the same file, where each
program runs under it's own user/group... the whole thing doesn't work
anymore.
Well at least not without ACLs or groups trickery.



I guess the following would definitely need quite some work to realise
but might be worth....
Ideally I think the following would be possible:

- The users/groups of these packages (the ones under which they run,
e.g. the icinga, nagios or nrpe daemon) is configurable via debconf,
with some sane default.
Maybe the default could be just as now (all nagios) or could already
start some separation (e.g. nagios runs as nagios, icinga as icinga,
nrpe as nrpe, and so on)

- if files/dirs are to be read and or written by other programs, e.g.
status.dat of nagios/icinga, then the respective package asks via
debconf, which user(s) should be granted such access.
All the file permissions (and if necessary: configuration settings)
should then be set automatically.

- optionally, if a package requires access to some DB (e.g. -idoutils,
-web) hints could automatically be given, on how to configure this.
I don't talk about a full description of e.g. pg_hba.conf and all the
ways of peer/ident/password/etc. authentications.... but I mean
something like:
"You selected to access the DB via unix/sockets  AND  to have Icinga run
as the UNIX user "icinga". Therefore you need to configure your DB, to
grant the UNIX user "icinga" peer/ident access".




The first question is probably whether the maintainers want to support
parts or all of the above (even if only on a _long_ term scale).

Then one could discuss problems and further improvements to these ideas.

I surely could help with tips on how I did the user privilege
separation... and so far I have everything separated (except icinga-web,
which I'm just about to try out how to do)



Curious for your thoughts,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5677 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-nagios-devel/attachments/20120621/2cf69334/attachment.bin>