<div dir="ltr">Hi, I wanted to get opinions on this.<div><br></div><div>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:</div><div><br></div><div><div>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`</div></div><div><br></div><div>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".</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>What are their options?  I can think of three:</div><div>1. They can refuse to use a Xymon client.</div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers</div><div>Jeremy</div><div><br></div></div>