[Nagiosplug-devel] [RFC] Plugins config file

[John P. Rouillard]

In message <20061016111350.GB15099 at openfusion.com.au>,
Gavin Carr writes:

>  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?

The way I do it is to use a small shell script to parse a password
config file and create a temp file. Then I pass the temp file to the
plugin. Obviously this works only with my own plugins, but it does
allow formatting and other changes. E.G. I can:

    pass URL's in a file
    create curl config files
    create user:passwd authentication formatted entries

and the input file tries to reuse plugins's normal authentication
mechanism setting the internal variable from a file rather than on the
command line.

Also I can run the command inside a here document in a shell script and
pass password info on stdin to the plugin if it accepts it.

wget -i << EOE
https://`getpw /password/cache -`@example.com/ 
EOE

which doesn't leave authentication info in the environment or on the
command line.

>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).

Sounds like a good idea and it should be simple enough to code in
perl, C, Bourne shell and python for starters. What may be better is
for the <auth-section> to be:

    auth-section:/path/to/auth/file

since I can see multiple auth files for different people to
maintain (e.g. oracle db's maintain the password for the test users
using on their databases).

My little getpw script takes:

  /path/to/file output_file_basename [token]

where the credentials (and their output format) are uniquely
identified by the file path and the token (where the token is similar
to your auth-section). So I can get the updates when the web admins
change the manager password on the servers without giving them access
to the passwords for other test users in LDAP.

				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.