[Nagiosplug-devel] [RFC] Plugins config file

[Thomas Guyot-Sionnest]

The blank-out workaround does not work on all system as it is usually
possible to prevent programs from rewriting their command line. This is a
good security feature to prevent rogue programs from renaming themselves to
a running daemon (ex a SMTP spambot uploaded in /tmp could rename itself as
httpd in a web server).

Thomas

> -----Original Message-----
> From: nagiosplug-devel-bounces at lists.sourceforge.net 
> [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On 
> Behalf Of Ton Voon
> Sent: October 16, 2006 9:46
> To: Nagios Plugin Development Mailing List
> Subject: Re: [Nagiosplug-devel] [RFC] Plugins config file
> 
> 
> On 16 Oct 2006, at 12:13, Gavin Carr wrote:
> 
> 
> 	I've got a perl nagios plugin that performs arbitrary 
> queries against
> 	a database and reports status codes based on the number of rows 
> 	returned i.e.
> 
> 	  Usage: check_db_query_rowcount [-v] -q <query> -w 
> <warn-count> 
> 	            -c <crit-count> -d <dsn> -u <user> -p <pass>
> 
> 	An obvious security problem with this is that the user 
> must pass the
> 	database credentials on the command line, which typically means 
> 	they're exposed to any local users via the process list 
> for however 
> 	long the plugin executes.
> 
> 	This must be a problem for lots of other kinds of plugin too - 
> 	anywhere you need to pass any kind of secret to a 
> plugin. Is there a
> 	good way of dealing with this that I'm not aware of?
> 
> 
> If you run mysql (I'm on 4.1.11) with -u user -ppassword, the 
> process table will have the password blanked out. I've done 
> that in C (see check_mysql_query), but I don't know how to do 
> that in perl. Would that be sufficient?
> 
> 
> 	My suggestion is that we introduce a config file 
> specifically for use
> 	by plugins (e.g. /etc/nagios/plugins.cfg or 
> 	$NAGIOS_HOME/etc/plugins.cfg), for arbitrary per-plugin 
> parameters we 
> 	don't want to have to pass at the command line. Perhaps 
> an INI-style 
> 	format would make sense, with per-plugin sections, or arbitrary 
> 	section names specified explicitly e.g.
> 
> 	  [ check_db_query_rowcount ]
> 	  dsn = db:Pg:database=foo
> 	  user = fred
> 	  pass = secret
> 
> 	or perhaps if I want to check multiple different 
> databases, or share
> 	the credentials across plugins:
> 
> 	  [ foo_db ]
> 	  dsn = db:Pg:database=foo
> 	  user = fred
> 	  pass = secret
> 
> 	Then my plugin could have a usage pattern like this:
> 
> 	  Usage: check_db_query_rowcount [-v] -q <query> -w 
> <warn-count> 
> 	            -c <crit-count> [--auth=<auth-section>]
> 
> 	where auth-section might default to the plugin name if 
> not specified
> 	(and the plugin would fail if an appropriate auth 
> section could not 
> 	be found).
> 
> 	Thoughts/comments?
> 
> 
> A design principle I've been following, although it is 
> undocumented and I'm all for starting a discussion about it 
> again, is that plugins should run without any knowledge of 
> state (I think the check_log plugin might break this - I 
> haven't worked closely on that one). A config file for 
> passwords doesn't sound necessary.
> 
> However, I guess this is no different from mysql having a 
> my.cnf file, so I don't think security gets any worse. My 
> angle is that the userid/password used should only have just 
> enough access to do the necessary check and no more. That 
> would be an application issue, not a plugin one.
> 
> Ton
> 
> 
> http://www.altinity.com
> T: +44 (0)870 787 9243
> F: +44 (0)845 280 1725
> Skype: tonvoon
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3076 bytes
Desc: not available
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20061016/4f98a6b1/attachment.bin>