[Pkg-nagios-devel] Bug#659928: Bug#659928: icinga-cgi: icinga users improvements

[Michael Friedrich]

Christoph Anton Mitterer wrote:
> Am 15.02.2012 08:32, schrieb Alexander Wirt:
>>> Some things I've noticed:
>>> a) Why are the icinga user/group and command user/group the same?
>>> Don't we miss privilege separation by this?
>> ?
> Well it seems upstream suggests running these as different users?!

upstream shows an example how it works. it does not really matter if you 
seperate the commandgroup from the icingagroup, it's just kept there for 
an easy install. packagers might do it different, as they can't just use 
"make install-commandmode" like one installing from sources.

>
>
>>> I haven't checked yet whether this sets just some config defaults or 
>>> not...
>>> have you an idea? I mean can it easily be changed?
>>> (Actually I must admit, that I don't know (yet) what the command 
>>> user is used for).
>> ?
>> Sorry, I don't understand what you want.
>
> AFAIU the command user is used to allow executing commands, right? 
the only purpose of providing those configure params is to set that 
values when invoking "make install-commandmode" as explained above. 
other parts of icinga are not using COMMAND_OPTS for their authorization.


> Now when this is the same then the icinga user (both nagios) someone 
> who would only need the command user could possibly also attack stuff 
> running as icinga user?!

how would some actually attack a core daemon which drops privilegues 
after startup being run as icinga_user/group, depending on the var/rw 
dir with group sticky bit to inherit the command group from what the 
admin has set to that?

sure, you could add a seperate group and add the apache user in there, 
putting the upstream example to packagers. the benefit will remain not 
that good. if you are eager on security, make sure your 
plugins/eventhandlers/notificationscripts can only be run by the icinga 
user itsself, not the group. everything else "running as icinga user" 
needs further clarification by yourself.
>
>
>>> b) web user / www-data
>>> While this is good for works-out-of-the-box(TM) it's bad for security
>>> (no privilege separation, which can be easily done by mod_suexec, or 
>>> fastcgi).
>>> As far as I can see (tell me if I'm wrong) this is _ONLY_ used in:
>>> debian/rules:    chgrp www-data ${b}/icinga-common/var/cache/icinga
>>> debian/rules:    chown root:www-data 
>>> ${b}/icinga-common/var/lib/icinga/rw
>>>
>>> So couldn't we make this configurable via debconf?! I.e. defaulting 
>>> to www-data
>>> but giving the user the choice to use something different?
>> Nope. Running apache as anything else than www-data is not really 
>> supported.
>> This package is designed to work out of the box and not to do debconf
>> abusing.
>
> Well this is even integrated in the apache packages themselves,... to 
> run several apaches all under different users.
> And even if you have just one, you can easily change the user of your 
> cgi by modsuexec, which should be done in any reasonable environment.

creating overhead for what benefit then? so-called better security with 
different users for a fifo where no further auth mechanisms are provided 
by the core itsself?

>
> I don't see how this would prevent it from running out of the box,... 
> just make it less manuall work by doing all calls to dpkg-statoverride 
> automatically.
> Would also save the users from finding out which locations they have 
> adapt.

users are highly advised to consult the README.debian and actually 
understand their content. if you did not get the hint, and did a plain 
"apt-get install icinga", you should at least consult the upstream 
website and their docs and wiki sections, where such pointers are added 
as well.

https://wiki.icinga.org/display/howtos/Setting+up+Icinga+with+IDOUtils+on+Debian

and if it doesn't fit, the change the COMMAND_OPTS yourself, and build 
the super-duper security package. security exploits happen for the cgis 
mostly btw.



>
>
> Chris.
>
>
>


-- 
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