[Xymon] Feature request: safe logfetch
Jeremy Laidman
jlaidman at rebel-it.com.au
Fri Dec 18 04:57:57 CET 2015
Hi, I wanted to get opinions on this.
I make extensive use the backticks feature of the "file:" configuration
option in client-local.cfg, to run little scripts on my clients. The
intended use is to report on dynamically-determined filenames. However, I
(ab)use it to run little scriptlets on client boxes and report back to the
Xymon server. Something like this:
file:`FILE=/tmp/array_status; LIFETIME=1d; [ -f "$FILE" -a -r "$FILE" -a -s
"$FILE" ] || exit 1; find "$FILE" -ctime -1 | grep ^ >/dev/null || exit 1;
( COLOR=green && STATUS=OK; egrep "rebuilding|expanding|ready for recovery"
$FILE >/dev/null && COLOR=yellow && STATUS=WARNING; grep "DEGRADED" $FILE
>/dev/null && COLOR=red && STATUS=ALERT; echo "status+$LIFETIME
$MACHINE.RAID $COLOR $(date) RAID $STATUS"; head -20 $FILE; ) | $BB $BBDISP
@ >/dev/null`
This will look in the file /tmp/array_status (updated every 5 minutes from
cron) and alert based on strings such as "DEGRADED" or "rebuilding".
This is awesomely useful, and makes Xymon extremely flexible. These
scriptlets can essentially replace simpler "ext" scripts on the client, and
can be entirely managed on the server side.
However, it's really not very secure, because the Xymon server can run any
code on the client box as the xymon user, without any form of
authentication. The only reason I'm comfortable doing this is that I
manage both (Xymon) client and server hosts. But the day may come when I'm
asked to monitor someone else's host, and they won't be happy for me to run
arbitrary commands on their host. Worse still if they're silly enough to
run their Xymon client under a privileged account, although some people
allow the xymon user to use sudo.
What are their options? I can think of three:
1. They can refuse to use a Xymon client.
2. They can disable logfetch (eg remove the "logfetch" command from the
xymonclient.sh script, or "chmod 0 logfetch", or rename and symlink to
/bin/true). But this means we miss out on logfile monitoring.
3. On some systems they could prevent logfetch from using the exec() system
call, such as using an selinux policy, or using a wrapper that declares its
own void functions for the exec*() suite system calls, like sudo's "noexec"
option.
What I'd like is to be able to tell the sysadmin to run his client in a
"secure logfetch" mode that forbids exec() system calls. Then she'll be
happy that this attack vector is closed, and that I can't run arbitrary
commands on her host. Perhaps there could be a LOGFETCH_OPTS variable that
can have "--noexec" added to the command-line for running logfetch, which
would enable the secure mode.
Cheers
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20151218/ca1213d6/attachment.html>
More information about the Xymon
mailing list