Security Concerns about the nsca daemon

[sean finney]

hi andreas, marc,

On Tue, Feb 21, 2006 at 01:48:14AM +0100, Andreas Ericsson wrote:
> Marc Haber wrote:
> >I would be more comfortable if it would be easily possible to run nsca
> >chrooted. If the chroot is sufficiently minimal, exploting privilege
> >escalation bugs from inside the chroot is significantly harder than if
> >a full system including all binaries would be visible.

i don't think this would be too difficult to do.  after the wishlist
bug in the debian BTS, i touched up with some r'ing of tfms and
i think the code to do this would be very small indeed (one line to
actually do it, a small number more for error checking and parsing
the config option).

> Normally, /var/empty is used. It is supposed to have mode 01700 and be 
> owned by root:root, which means it's as secure as it can get.

unfortunately, i see no way of chrooting anywhere but the
directory containing the command fifo (read on for my rationale).

> I've got a nifty snippet that does this in a secure fashion that also 
> prevents chroot jail breakouts (which bind had troubles with at first). 
> I'm not sure how portable it is though, but for the nsca daemon that 
> shouldn't be extremely important.

i *believe* all you need to do to prevent chroot breakouts in linux
is change to the directory first, and then renounce your superuser status
(you need root/CAPB_CHROOT to chroot in the first place).  of course it
would be much nicer if linux supported something like the *bsd jail()
interface, but afaik there isn't any such capability... only a bunch of
poor understandings by linux developers of what "jail" means.

> This is trickier. Currently, FIFO is emptied continuously in a separate 
> thread that *only* polls the socket. Creating another thread to check 
> one more FIFO is not a good idea, as lots of code need to be made 
> reentrant (i.e. they need to be capable of safely executing in several 
> threads at one time). Another option is to make the current thread 
> multiplex several FIFO's, but that too is a far from simple solution.

i'm not sure what's going on in the code right now, but if we're
just using poll() on the current FIFO, it wouldn't be too hard
to pass 2 pollfd structs instead of one (through the same poll
call even).  the only tricky part afaict would be balancing the actual
reading so that one fd doesn't starve the others, but this could be done
fairly easily too by rotating which fd to start with.  something like:

while(start_index=++start_index%numfds){
	poll(ufds, numfds, timeout)
	for(i=0;i<numfds;i++){
		nextfd=(start_index+i)%numfds
		if(needs_read(ufds[nextfd])) do_some_reading(ufds[nextfd]);
	}
}

and i don't think it'd be too much harder with select() if that's
what we're using.  of course, if the only thing the thread
is doing right now is a blocking read on the one socket.... :)

> Fortunately, it's also completely unnecessary. A process can open(2) a 
> file, FIFO or socket prior to doing a chroot and then write(2) to it 
> from the chroot jail, even though the file (or FIFO, or socket) doesn't 
> reside anywhere below that path.

yes, but if someone restarts nagios, the command fifo is closed and
reopened, leaving the nsca process stranded.  this could be fixed
by patching the init script for nagios to restart the nsca
process, but imo that puts the responsibility in the wrong place.
personally, i think chrooting in the same directory as a command
fifo (and making sure that the nsca daemon does not have write access
to '.' or anything else but the cmd fifo) is the way to go.


	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20060221/28f1840f/attachment.sig>