A few points to this:<div><br></div><div>* a webserver with hosting is not the place for an Icinga/Nagios</div><div>  installation if you have security concerns</div><div><br></div><div>* your ideas might be good, but to complex to support and maintain</div>

<div><br></div><div>* if you have special needs to a software installation the "default" Debian</div><div>  package might not be you best choice, build your own package</div><div>  (use ours as example)</div><div>

<br></div><div>* a Debian package is designed to fit the needs of a majority of users</div><div>  and provide a simple way of installing a software</div><div><br></div><div>Regards</div><div>-Markus</div><div><br></div><div>
<div><div class="gmail_quote">2012/6/21 Christoph Anton Mitterer <span dir="ltr"><<a href="mailto:calestyo@scientia.net" target="_blank">calestyo@scientia.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi.<br>
<br>
I didn't want to open a wishlist bug immediately but rather ask for<br>
thoughts here now.<br>
<br>
With both, icinga and nagios, as well as other befriended stuff (NRPE,<br>
IRPE, icinga-web, PNP4Nagios, etc. pp.) we have many stuff running under<br>
some user and also many files owned by some user/group.<br>
<br>
Right now all these user/groups seem to be simply set to a combination<br>
of nagios:nagios www-data:www-data or a mix of these.<br>
<br>
<br>
Well,... IMHO that could be improved with respect to user-privilege<br>
separation... for all the well known security-related advantages (guess<br>
I don't need to discuss these).<br>
<br>
Some simple examples:<br>
1) On could have a system where e.g. both nagios and icinga runs.<br>
Perhaps for different customers. They use the same users/grous and are<br>
therefore more easily attackable in case one of them is successfully<br>
attacked.<br>
<br>
2) A system where nagios|icinga && NRPE|IRPE runs... if NRPE|IRPE is<br>
successfully attacked, nagios|icinga are, too.<br>
<br>
<br>
3) Of specific concern for me personally is the use of www-data.<br>
For security reasons I dislike using apache-mod-php, as everything is<br>
run under the context of the webserver. If just a single PHP suite<br>
hosted on the server in any vhost has a hole... all the others are<br>
likely attackable, too.<br>
<br>
Which is why I personally use PHP via CGI,... and run (and really<br>
enforce this) each PHP suite hosted on a server as a different<br>
cgi-something user.<br>
e.g. cgi-phpbb, cgi-icinga (for the classic web), cgi-icinga-web (for<br>
the new web), cgi-davical (a caldav server).<br>
<br>
4) Another advantage of this is, that you can easily and securely<br>
separate access permissions to databases in e.g postgresql.<br>
As each web-app runs under it's own user, I simply authenticate via peer<br>
authentication over unix sockets.<br>
No need for (always somehow hackable passwords, that need to be<br>
maintained and configured).<br>
<br>
<br>
Now quite obvious, most things than don't work with such separation at<br>
first, as access rights are missing.<br>
Right now there are two ways of handling this:<br>
1) Manually setting rights and always doing this again when some update<br>
occurred.<br>
=> annoying but has the advantage that you don't forget any entries in<br>
dpkg-statoverride, in case they should no longer be needed<br>
<br>
2) dpkg-statoverride<br>
=> works automatically to some extent, but not when new files are added<br>
that need adjusted permissions<br>
=> you likely forget to remove overrides, in case they should be no<br>
longer needed at some point<br>
<br>
3) Problem of all of them:<br>
If more than on program needs access to the same file, where each<br>
program runs under it's own user/group... the whole thing doesn't work<br>
anymore.<br>
Well at least not without ACLs or groups trickery.<br>
<br>
<br>
<br>
I guess the following would definitely need quite some work to realise<br>
but might be worth....<br>
Ideally I think the following would be possible:<br>
<br>
- The users/groups of these packages (the ones under which they run,<br>
e.g. the icinga, nagios or nrpe daemon) is configurable via debconf,<br>
with some sane default.<br>
Maybe the default could be just as now (all nagios) or could already<br>
start some separation (e.g. nagios runs as nagios, icinga as icinga,<br>
nrpe as nrpe, and so on)<br>
<br>
- if files/dirs are to be read and or written by other programs, e.g.<br>
status.dat of nagios/icinga, then the respective package asks via<br>
debconf, which user(s) should be granted such access.<br>
All the file permissions (and if necessary: configuration settings)<br>
should then be set automatically.<br>
<br>
- optionally, if a package requires access to some DB (e.g. -idoutils,<br>
-web) hints could automatically be given, on how to configure this.<br>
I don't talk about a full description of e.g. pg_hba.conf and all the<br>
ways of peer/ident/password/etc. authentications.... but I mean<br>
something like:<br>
"You selected to access the DB via unix/sockets  AND  to have Icinga run<br>
as the UNIX user "icinga". Therefore you need to configure your DB, to<br>
grant the UNIX user "icinga" peer/ident access".<br>
<br>
<br>
<br>
<br>
The first question is probably whether the maintainers want to support<br>
parts or all of the above (even if only on a _long_ term scale).<br>
<br>
Then one could discuss problems and further improvements to these ideas.<br>
<br>
I surely could help with tips on how I did the user privilege<br>
separation... and so far I have everything separated (except icinga-web,<br>
which I'm just about to try out how to do)<br>
<br>
<br>
<br>
Curious for your thoughts,<br>
Chris.<br>
<br>_______________________________________________<br>
Pkg-nagios-devel mailing list<br>
<a href="mailto:Pkg-nagios-devel@lists.alioth.debian.org" target="_blank">Pkg-nagios-devel@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-nagios-devel" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-nagios-devel</a><br></blockquote></div><br><br clear="all"><div>

<br></div>-- <br>Markus Frosch<br><a href="mailto:markus@lazyfrosch.de" target="_blank">markus@lazyfrosch.de</a><br><a href="http://www.lazyfrosch.de" target="_blank">http://www.lazyfrosch.de</a><br>
</div></div>