Bug 185685

Created attachment 126253 [details]
Replacement conf file

It's good practice to only listen to localhost on default install.  And Nagios
doesn't work without authentication by default so that was my reasoning behind
the restrictive perms.  How about the following default setup instead (with the
changes from your patch)

ScriptAlias /nagios/cgi-bin/ /usr/lib/nagios/cgi-bin/
<Directory /usr/lib/nagios/cgi-bin/>
   Options ExecCGI
   order deny,allow
   deny from all
   allow from 127.0.0.1
   AuthType Basic
   AuthUserFile /etc/nagios/passwd
   AuthName "nagios"
   require valid-user
</Directory>

Alias /nagios /usr/share/nagios/html/
<Directory /usr/share/nagios/html/>
   Options None
   order deny,allow
   deny from all
   allow from 127.0.0.1
   #AuthType Basic
   #AuthUserFile /etc/nagios/passwd
   #AuthName "nagios"
   #require valid-user
</Directory>

In this senario you can atleast load up a page from localhost without
authentication.  Any testing beyond that (using CGI's) requires extensive
configuration of Nagios anyway.

My main concern is giving access to the cgis, afterall, cmd.cgi is designed to
run commands on the local machine via the nagios.cmd file.  I think its best to
keep it locked down pretty tight.

What are your thoughts?

Executing via cmd.cgi is locked down already via the config file, so it's a
non-issue.  Normally I'd agree with any efforts to secure a default install, but
honestly I think it's a bit much here for no real gain.

Nagios by default doesn't let anyone do anything (or even see much) with a
default install and most people are going to be doing an install on a remote
machine.  Imagine the frustration for a newbie trying to figure out why their
shiny new install doesn't work.  That person is not going to know they should be
looking at an apache conf file, they will just assume there's something wrong
with our packages (or spam forums/mailing lists).

I'd strongly recommend using a permissive default with the more restrictive
lines commented out with detailed instructions.  That way folks will see the
rationale and hopefully go with the more secure access, but won't run into
issues with the install.

I hope this makes sense... Haven't had enough cafeine yet to tell... ;)

I think the main reasoning behind this isn't the way it works when its installed
but to protect against an unconfigured service getting exploited by a
vulnerability that comes out later.  I'll make the restrictions lighter if you
can find another Fedora web package that has ligher restrictions.  I don't want
to be inconsistant with what the other packages are doing.

What tests need to be run to verify that Nagios is installed correctly?  (Aside
from the significant config work needed to be done to get the Nagios daemon running)

Meh... I didn't realize the host restrictions were a FC standard. I still have
my objections, but this isn't the right forum...

I don't really know of any tests (other that bringing up localhost/nagios) that
could be automagically run at install time.  As you noted, nagios is useless
till the daemon is configured.

Just following up on this, would you mind if I closed it?

Feel free...

Closing this for now but will continue to consider an easier way for users to
test their install.