[Xymon] Feature request: safe logfetch

[J.C. Cleaver]

Thanks, Jeremy.

Lots of good ideas in this. Responses inline.


On Thu, December 17, 2015 7:57 pm, Jeremy Laidman wrote:
> 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.

One way of getting around this, at the expense of not
fully-controlled-via-server configuration, is to have ext scripts (or
/local/, or (in a packaged world) /sections) wrap the contents of whatever
file you want to examine into a 'msgs:' compatible format. xymond_client,
which is doing the analysis.cfg doesn't know or care that a section was or
wasn't created by logfetch per se. Once it's in the clientlog by any
means, processing can complete as normal.


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

Yeah, no. Even outside of CVE-2006-3373 there's no reason to execute the
xymon client as root, period. Ever. If it's logfetch in particular, privs
can be added at the minimum needed (by the local admin) to read necessary
log files using either group privs, facl's, or something similar.

Anything that truly needs root access to collect can be deposited to a
temp file for later pickup by a 'xymon' user task, and/or submitted up to
the xymon server directly.

Being able to run as an unprivileged user, thus limiting exposure from
alternate execution channels like this, is a significant benefit of xymon,
and we should work to prevent folks from trying to undermine that.


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

I think an selinux policy could be added in, but it would be difficult to
make the default policy. It would also prevent the use of directory disk
space commands, (although I'm not sure how often that gets used).


> 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

I think --noexec is a good first step and it should be fairly trivial to
add in. Similar to --download being disabled, it eliminates a class of
possible issues there.


To some extent the question of logfetch control is really a question of
config download control. One of the patches waiting to go in to 4.x is a
flag for separating out client submission from client-local.cfg response
into two distinct messages. This was initially for performance reasons (it
allows a whole class of communication to move from two-way TCP hits on
xymond to one-way drops onto the BFQ and less-frequent config updates),
but also gives much more control of config updates overall.

Instead of doing it via client-local.cfg at all though, it'd trivial to
integrate it with whatever other config management or deployment mechanism
you have. It seems like control over that channel would sort of go
hand-in-hand here for installations where this is a concern.


Regards,
-jc