[Nagiosplug-devel] [RFC] Plugins config file
Thomas Guyot-Sionnest
Thomas at zango.com
Mon Oct 16 22:19:21 CEST 2006
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: <http://nagios-plugins.org/archive/devel/attachments/20061016/4f98a6b1/attachment.bin>
More information about the Devel
mailing list