[Nagiosplug-devel] Check Ping rewrite

[Jeremy T. Bouse]

	I tend to agree with yo, even though I've been looking into
what implementation of a  raw ICMP routine would entail... I agree with
you completely on security auditing of it as I make my living as a
network administrator I'm always concern'd about the security
implications on my servers...

	I don't think I need to make any major change to the configure
script than what I have now for determining the PING_COMMAND and
PING6_COMMAND if IPv6 support has been found... For ICMPv6 ping I first
check for the existence of 'ping6' which several platforms have (namely
Linux, the various BSDs, Mac OS X) and if that fails to be found try
calling 'ping' with '-A inet6' for systems that have a ping command that
supports both (namely Solaris so far)... In check_ping I just need to
#ifdef based off the existence of USE_IPV6 and then make it call either
PING_COMMAND or PING6_COMMAND based on the address given... I can have
this out the door by Friday I think...

	The configure script does allow the user running configure to
specify the command syntax via --with-ping-command and
--with-ping6-command however I've noted one odd behavior with the way it
is handled... If the command syntax is given in this manner it
automatically assumes PING_PACKETS_FIRST or PING6_PACKETS_FIRST which is
not always the case... I'm not quite sure how to handle this case as
I've only encounter'd where I've had to specify it once (on a Solaris 8
machine with IPv6 support but no IPv6 interfaces thus fails the checks
which attempt to ping ::1 [ip6-localhost]) so far...

	The above paragraph makes note of one flaw I've found in
configure testing for ICMPv6 ping support and that is if the plugins are
built on a machine with IPv6 support but doesn't have IPv6 enabled on
atleast the loopback interface the tests will fail for PING6_COMMAND and
you will end up with USE_IPV6 being defined but PING6_COMMAND being left
empty... One solution, although I think it would be faulty, would be to
use the same arguments given to PING_COMMAND using 'ping6' if it's
available or 'ping -A inet6' if ping6 isn't available... But this could
be incorrect if they don't use the same command line args... I'm open to
suggestions for making this testing better...

	I think check_icmp will be put on my list as a 'pet project' as
making check_ping work AF-independently is priority to creation of a new
routine from scratch... 

	Jeremy

On Thu, Mar 13, 2003 at 10:25:53AM -0500, Karl DeBisschop wrote:
> I've expressed before that I'm quite concerned about doing ICMP
> natively, since that will require a setuid root binary on most systems.
> 
> While I've definitely backed off my initial reservations somewhat, I
> still have them.
> 
> When we get around to this issue, I'd like to suggest a new plugin,
> 'check_icmp' that make the network calls, keeping check_ping more or
> less as it is.
> 
> Additionally, I'd like to consider keeping the existing ping sysntax
> checks more or less as they are, but making the result of configure be
> the DEFAULT invocation of ping. letting the users provide and alternate
> systax at run time via a command line switch.
> 
> I just can't shake the fear that we really up the security concerns we
> have to face once we start shipping a setuid plugin in the core. So by
> the above plan, we provide the utility, but don't force people to use
> it.
> 
> Also, before we release a check_icmp, I'm going to want to see A LOT of
> checking. It will need to compile very srtictly with no warnings, and it
> will need to pass any lint-type utility or purify equivalent or wahtever
> before I'll be comforatable with shipping something steuid root with the
> intention that every Nagios install out there might run this for
> check_host_alive. The risks seem very large to my mind.
> 
> Good, now I've got that off my chest....
>