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

Thu Jun 21 17:18:11 UTC 2012

Christoph Anton Mitterer wrote:
> Hi.
>
> I didn't want to open a wishlist bug immediately but rather ask for
> thoughts here now.

i haven't read all the text masses you've been producing, but excuse my 
question - sure you are using the proper distribution for your concerns? 
wouldn't it be better to join the openbsd community, or fork your own 
little space where you're in a safe location?

jm2c,
michael

>
> 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.
>
>
> _______________________________________________
> Pkg-nagios-devel mailing list
> Pkg-nagios-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-nagios-devel

-- 
DI (FH) Michael Friedrich

Vienna University Computer Center
Universitaetsstrasse 7 A-1010 Vienna, Austria

email:  michael.friedrich at univie.ac.at
phone:  +43 1 4277 14359
mobile: +43 664 60277 14359
fax:    +43 1 4277 14338
web:    http://www.univie.ac.at/zid
         http://www.aco.net

Lead Icinga Core Developer
http://www.icinga.org