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.friedr...@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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
