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

[Alexander Wirt]

Christoph Anton Mitterer schrieb am Donnerstag, den 21. Juni 2012:

> 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).
No from my side.

Alex

-- 
Alexander Wirt, formorer at formorer.de 
CC99 2DDD D39E 75B0 B0AA  B25C D35B BC99 BC7D 020A