Security Concerns about the nsca daemon

Andreas Ericsson ae at op5.se
Wed Feb 22 14:18:52 CET 2006


Marc Haber wrote:
> On Wed, Feb 22, 2006 at 11:03:51AM +0100, Andreas Ericsson wrote:
>>
>>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.
> 

In that case I'd argue setting up /jail with a full environment in it 
and include an empty directory where Nagios will create its command-fifo.


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

They are. The only reason to have a separate jail for a daemon is if 
that daemon needs to write files inside the jail (bind and dhcpd does 
this, f.e.). The correct, safe and sane way of entering a chroot jail 
goes like this:

	pw = getpwnam(pseudo_user);
	chdir(jail);
	chmod(".", 0000);
	chroot(".");
	setresgid(pw->pw_gid, pw->pw_gid, pw->pw_gid);
	setresuid(pw->pw_uid, pw->pw_uid, pw->pw_uid);

Naturally, all system calls need to be verified properly. setresgid and 
setresuid should be checked like so:

	gid = pw->pw_gid;
	uid = pw->pw_uid;
	if (getegid() != gid || getgid() != gid)
		failed();
	if (getuid() != uid || geteuid() != uid);
		failed();

Note that if the daemon doesn't drop its privileges it could probably 
interfere with just about any other program on the system (through 
signals), but that has no impact what so ever on daemons sharing a jail.

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

Writing code "just to make sure" is a good way of wasting time and 
adding code-bloat. When someone needs it, they'll write it. When someone 
else may need it sometime in the future, it stays unwritten.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231


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




More information about the Developers mailing list