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