[Xymon] XyMon client binaries default security is bad

cleaver at terabithia.org cleaver at terabithia.org
Fri Mar 1 21:40:40 CET 2013


It does partially depend on umask, however it's also a larger issue of how
the client package is deployed in the first place.

If a binary shouldn't be run, and it exists in someone's (or something's)
home directory, directory privs should be modified as well. The annoyance
of users not being able to query (without switching users) might be a
non-issue, depending on your local policies.

For RPM-based installs, it's a little bit different.


Keep in mind that bogus reports can be sent from a specific host about
itself by a local user anyway, though. See
http://www.xymon.com/xymon/help/xymon-tips.html#noinstall, which
definitely puts us into the "bug or feature?" realm.

--status-senders doesn't help here either:

"By default, any host can send status-updates. If this option is used,
then status-updates are accepted only if they are sent by one of the
IP-addresses listed here, or if they are sent from the IP-address of the
host that the updates pertains to (this is to allow Xymon clients to  send
 in  their  own status updates, without having to list all clients here).
So typically you will need to list your servers running network tests
here."


Perhaps user/pass authentication could be added, but "real" security at
the report-submission level would be SSL-handshaking at the port with any
local keys controlled by standard unix/host access controls, (or HTTPS and
xymonmsgcgi.msg and appropriate user/pass auth info after the SSL tunnel
is set up). The bits and pieces are in trunk, but I'm not sure what their
current working state is...

Perhaps Henrik can chime in?


Without SSL, setting more restrictive perms seems more helpful in keeping
people from messing around with your install than anything else.


Regards,
-jc




> It could allow bogus reports to be sent to the Xymon server, maybe hiding
> something malicious.
>
> Also, a lot of security scans will pick up on things that are world
> executable and not in one of the standard directories (like /usr/bin,
> /bin,
> etc.).
>
> Thanks,
> Larry Barber
>
> On Thu, Feb 28, 2013 at 9:37 PM, Jeremy Laidman
> <jlaidman at rebel-it.com.au>wrote:
>
>> What's wrong with non-xymon users executing these commands?  What harm
>> could it do?
>>
>>
>> On 1 March 2013 08:59, Andrey Chervonets <a.chervonets at cominder.eu>
>> wrote:
>>
>>>  upgraded XyMon (clinet) to 4.3.10 (the same was at least in 4.3.5) and
>>> notices all files in bin can read and execute privileges to everyone:
>>>
>>> ls -l client/bin/
>>> total 1840
>>> -rwxr-xr-x  1 xymon monitor 161079 Feb 28 21:08 clientupdate
>>> -rwxr-xr-x  1 xymon monitor 200250 Feb 28 21:08 logfetch
>>> -rwxr-xr-x  1 xymon monitor 151256 Feb 28 21:08 msgcache
>>> -rwxr-xr-x  1 xymon monitor 153905 Feb 28 21:08 orcaxymon
>>> -rwxr-xr-x  1 xymon monitor 156173 Feb 28 21:08 xymon
>>> -rwxr-xr-x  1 xymon monitor 133445 Feb 28 21:08 xymoncfg
>>> ....
>>>
>>> I suppose it depends on umask setting during installation, but I would
>>> be
>>> more happy if installation process setup more secured configuration
>>> regardless of default settings.
>>> At least:  -rwxr-x---
>>>







More information about the Xymon mailing list