[Nagiosplug-devel] Security discussion - don't run as root plugins
John P. Rouillard
rouilj at cs.umb.edu
Fri Jul 18 21:12:55 CEST 2008
Hendrik said:
>just a few moments ago I've read a question by a user if it would be a
>problem to run the nagios plugins with root right via check_by_ssh.
>
>Yes - I laughed too as I read that. But in the following discussion it
>clears up - they already have a spreaded root ssh key on most of their
>systems and are to lazy
There are a number of reasons to want to do this.
It's too complicated by policy. I know a couple of sites where the
operations/monitoring folks are not the admins of the systems, so trying to push such a change through would take weeks if not months.
It could be a technological issue, adding a nagios user to 1000
/etc/password files manually for example.
I agree it's not an approach I would want to use..
> to establish an unprivileged 'nagios' user on
>their systems - so they would run them as root.
Yeah running all plugins as root gives me the heebie jeebies too.
>I know, security awareness should be part of the persons who are using
>the tools, scripts and programs - but 80% of security holes came from
>people who didn't know what they are doing.
Yup that's true but it's what sysadmins are hired to do. Make the risk
assessment based on the business needs of the company. If nagios was
an end user tool, that would be a different story.
>Without starting a flame on this topic I would like to ask what do you
>think of some security benefits like:
>
>* don't run the code if UID is 0: Hard but effective - check uid and
> abort with a warning.
Well in some cases I have to run plugins as root as root is the only
person allowed access to the device/file.
I use a nagios account for intermachine access, and the nagios user
has a forced command that validates the command line before it's
executed and restricts what can be run. So I use sudo to log the
command that is run with elevated privs.
The alternative is to change the permissions on files, modify vendor
supplied log rotation configurations/scripts ... throughout the
enterprise. Then keep maintaining those changes throughout system
upgrades etc. Also I need to retrain every system scanner out there
that /var/log/messages should be root.nagios mode 640 etc. Finally
make sure new admins understand all the changes that may impact them
so they don't go and reverse them because rpm -V said it was wrong. A
major pain in the ... well, you get the idea.
>* try to drop the privileges to the given user by the configure run
> as a hard coded option
Again in my senario it would introduce more complexity that leads to
people doing other stupid stuff (/dev/mem mode 644 anybody, hey at
least it wasn't 666).
>I am not stupid enough to run my plugins with root privileges - but
>there are thousand of users out there who won't know what they're
>doing.
I am very selective in what plugins run as root, but I do have a
handful where overall security is improved by running them as root
rather then trying to open access to the monitored item.
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
More information about the Devel
mailing list