Security Concerns about the nsca daemon

[Marc Haber]

On Wed, Feb 22, 2006 at 11:03:51AM +0100, Andreas Ericsson wrote:
> Marc Haber wrote:
> >On Tue, Feb 21, 2006 at 05:35:53PM +0100, Andreas Ericsson wrote:
> >>Marc Haber wrote:
> >>>On Tue, Feb 21, 2006 at 03:34:22PM +0100, Andreas Ericsson wrote:
> >>>>Marc Haber wrote:
> >>>>>The directory to chroot to should be configurable at compile time to
> >>>>>help FHS-compliant distributions. On Debian, the directory to use
> >>>>>would be /var/run/nsca, by example of sshd.
> >>>>
> >>>>At run-time, I'd say.
> >>>
> >>>Even better, one would have to worry about input processing though.
> >>
> >>Not sure I follow you there.
> >
> >A compile-time setting will end up in a #define, so one can assume
> >that whatever is there isn't maliciously set.  For a run-time setting,
> >one must verify that the parameter is acutally a valid path name, that
> >no wildcard or relative path stunts are pulled, and one needs to go
> >through the hassle of string handling in C, which is always a source
> >for buffer overflow errors, which will have bad consequences at the
> >time of option parsing since we are not yet chrooted and still hold
> >root privileges at that point.
> >
> 
> No we don't. All we need to do is
> 
> 	path = slurp_path(nagios_config_file);
> 
> 	if (chdir(path) < 0)
> 		crash_horribly("Unable to chdir() to '%s'\n", path);
> 
> chdir() is a system call so shell metacharacters and the like are 
> completely ignored.
> 
> Nagios doesn't care if it's a relative path or riddled with symlinks 
> (well, it does, since it chdir()'s to '/' prior to opening anything, I 
> think), so we shouldn't either. It doesn't really matter one way or another.

I follow your expertise here.

> >Having multiple command_file directives is desireable, IMO, since one
> >could then run multiple instances of programs that can deliver
> >external commands (web, wap, nsca, e-mail, irc etc) to nagios, all of
> >them potentially chrooted. It's like adapting nagios for a general
> >thing, not just for nsca.
> 
> Nothing prevents multiple daemons running in the same chroot() jail. The 
> jail is still as secure as it would be if just one daemon was running 
> inside it.

That might be the case when the daemon can live with an empty chroot,
which is only true if the daemon can chroot itself. As soon as we need
external chroot techniques (which might be the case for third-party
daemons, not the patched nsca), the chroot needs contents, and then it
would be desireable to have one chroot per daemon.

Additionally, I am not so sure whether two daemons in the same chroot
are effectively prevented from doing bad things to their neighbor.

> >otoh, all of these interfaces could lead to send_nsca being called,
> >which would reduce the number of nagios interfaces to one: nsca.
> 
> Now I don't follow you again. Do you mean to call send_nsca from the 
> same host nsca is running on? That doesn't really make sense, since 
> programs calling send_nsca either must reside in a fully featured chroot 
> jail (i.e., one with a linker, libraries, /proc filesystem and whatnot) 
> or have send_nsca statically linked.

Yes, you're right. So it is desireable to have multiple command_file
directives just to make sure.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642