NRPE enhancement

[Dave Viner]

This sounds interesting, but I have a question about the security implications of this code.  I'm not a security expert, so please excuse the somewhat basic question.  The struct packet as defined in common/common.h has an argv member which is a character array of length 2048.   I believe this means that if the incoming packet has an argv member whose length is greater than 2048 chars, then the  
	rc=recvall(sock,(char *)&receive_packet,&bytes_to_recv,socket_timeout);
should fail, should it not?  

However, I think your suggestions regarding stunnel, and encryption are good ones, regardless of the inclusion of this code.

thanks

dave


-----Original Message-----
From: Carroll, Jim P [Contractor] [mailto:jcarro10 at sprintspectrum.com]
Sent: Friday, December 27, 2002 10:20 AM
To: 'Dave Viner'; Nagios-users at lists.sourceforge.net
Subject: RE: [Nagios-users] NRPE enhancement


I think it's a good idea, but with the following provisions:

- This should not be enabled by default.

- The configure script, the Makefile and any/all NRPE docs should explicitly
state the security risks in forcing the non-default (added feature)
behaviour.

- If the daemon is compiled with this option, anytime the daemon starts, it
should briefly mention that it has been compiled for this behaviour, and a
quick remark about the increased risks.  (Sent to stderr if standalone, else
sent to syslog if running under (x)inetd).  It should scream loud and clear
if it's started under root; preferably it would simply not run as root, full
stop.

- Perhaps a reference to implementing NRPE with stunnel (and only permitting
connections from localhost, as defined in nrpe.cfg) would be desireable.

I'm not a security guru, but it seems to me that facilitating this feature
would open oneself up to a buffer overflow attack.  If you're on a trusted
network, it's a non-issue.

On a related note, I'd be much more comfy with this feature if there were a
facility to enforce some level of native encryption, such as what NSCA uses.
If you don't have the keys to the house, you get dropped on the floor.  (I
have a similar wish for NSClient.)

Food for thought.

jc

> -----Original Message-----
> From: Dave Viner [mailto:dviner at yahoo-inc.com]
> Sent: Friday, December 27, 2002 11:48 AM
> To: Nagios-users at lists.sourceforge.net
> Subject: RE: [Nagios-users] NRPE enhancement
> 
> 
> In order to clarify the idea that I'm proposing, I've made a 
> patch to the nrpe source that implements what I'm describing. 
>  This patch is made against the nrpe-1.5.tar.gz from sourceforge.
> 
> Essentially, these changes allow us to specify in the 
> nrpe.cfg file lines like this:
>   command[check_disk_gen]=/usr/local/libexec/nagios/check_disk
> 
> Then when invoking check_nrpe, you can invoke it like this:
>   ./check_nrpe 127.0.0.1 -V 2 -c check_disk_gen -a "-w 50000 
> -c 10000 -p /dev/ad0s1e"
> 
> And the effect is that /usr/local/libexec/nagios/check_disk 
> is invoked with the -w 50000 -c 10000 -p /dev/ad0s1e as the 
> argument string.  For example:
> 
> ~/nagios/nrpe-1.5.new/src>./check_nrpe 127.0.0.1 -V 2 -c 
> check_disk_gen -a "-w 50000 -c 10000 -p /dev/ad0s1e"
> DISK OK - [1484108 kB (9%) free on /dev/ad0s1e]
> ~/nagios/nrpe-1.5.new/src>
> 
> I think this is really useful and would greatly reduce the 
> size of the nrpe.cfg and, more importantly, would reduce the 
> number of times you'd need to modify that configuration file. 
>  Instead the modifications would occur on the centralized 
> Nagios server's configuration file.
> 
> What does everyone think?  Should we add this to the main 
> source for NRPE-1.6?
> 
> dave
> 
> 
> -----Original Message-----
> From: nagios-users-admin at lists.sourceforge.net
> [mailto:nagios-users-admin at lists.sourceforge.net]On Behalf Of 
> Dave Viner
> Sent: Monday, December 23, 2002 8:51 AM
> To: Naios Users
> Subject: RE: [Nagios-users] NRPE enhancement
> 
> 
> Hi Rue,
> 	Security is a great reason for limiting the commands 
> that NRPE is able to execute.  But my suggested enhancement 
> wouldn't allow NRPE to execute any command that isn't listed 
> in the cfg file.  That is, the NRPE would still need to find 
> the path to the executable in the nrpe.cfg file, then use any 
> remaining information as arguments passed to the executable.  
> It is true that this is less secure that forcing the entire 
> command line (executable and arguments) in the config file.  
> But, so long as the executables are well authored and handle 
> unexpected arguments well, I think this enhancement would not 
> significantly decrease security.  Do you think that 
> specifying arguments would make NRPE significantly less secure?
> 
> 
> Dave
> 
> 
> -----Original Message-----
> From: nagios-users-admin at lists.sourceforge.net
> [mailto:nagios-users-admin at lists.sourceforge.net]On Behalf Of 
> Rue Turner
> Sent: Friday, December 20, 2002 1:33 PM
> To: Naios Users
> Subject: Re: [Nagios-users] NRPE enhancement
> 
> 
> dave,
> 
> I think the reson for this choice of configuration is security. If the
> nrpe was allowed to run whatever it was asked it would be easy to
> compromise your machines. This way although your configs are 
> hefty (mine
> have almost a hundred lines in) you can only ask it to run 
> commands from
> this library.
> 
> rue
> 
> 
> On Fri, 2002-12-20 at 17:35, Dave Viner wrote:
> > Hi,
> > 	I'd like to suggest an enhancement to NRPE, and if 
> people think this is a
> > good idea, I'll try to make a patch to support my 
> suggestion.  Currently the
> > nrpe.cfg file specifies all the commands in this fashion:
> > 	
> command[check_disk1]=/usr/local/nagios/libexec/check_disk 80 
> 95 /dev/hda1
> > As result of this design is that if you want to check something like
> > /dev/hda1 and /dev/hdb1, you need two seperate lines in the 
> nrpe.cfg file.
> > 	So, I'd like to propose that we extend NRPE to allow 
> for the arguments to a
> > command to be specified by the central Nagios server 
> instead of in the
> > nrpe.cfg.  The idea is that the nrpe.cfg would have one 
> command line which
> > maps a key, 'check_disk', to a local executable,
> > '/usr/local/nagios/libexec/check_disk'.  The rest would be 
> specified from
> > the central Nagios server in some manner.
> > 	I think this would great simplify the nrpe.cfg files, 
> and reduce a lot of
> > redundant command definitions that differ only in the arguments they
> > require.  Also, it would mean that you'd need to update 
> your nrpe.cfg very
> > rarely.  In fact, you'd only need to update it when you add 
> a new plugin.
> > 	I don't have a concrete suggestion for implementing 
> this yet, because I
> > want to see if the community is interested in this idea 
> first.  Has this
> > idea been suggested previously?  Is anyone currently 
> interested in the idea
> > or would I be the only consumer of such a service?
> > 
> > thanks
> > dave
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
> > Time is running out!  Thinkgeek.com has the coolest gifts for
> > your favorite geek.   Let your fingers do the typing.   Visit Now.
> > T H I N K G E E K . C O M        http://www.thinkgeek.com/sf/
> > _______________________________________________
> > Nagios-users mailing list
> > Nagios-users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nagios-users
> 
> 
>                       r u e  t u r n e r
>   · t · h · i · n · l · a · y · e · r · 
>  
> -- index, n.: Alphabetical list of words of no possible interest where
> an alphabetical list of subjects with references ought to be.
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
> Time is running out!  Thinkgeek.com has the coolest gifts for
> your favorite geek.   Let your fingers do the typing.   Visit Now.
> T H I N K G E E K . C O M        http://www.thinkgeek.com/sf/
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> 
> 




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf