[Xymon] XyMon client binaries default security is bad

Jeremy Laidman jlaidman at rebel-it.com.au
Fri Mar 8 02:30:10 CET 2013

On 7 March 2013 17:37, zGreenfelder <zgreenfelder at gmail.com> wrote:

> it's a common notion,

Really?  I've been in Win/UNIX/Internet security for 20 years, used various
scanners, applied many security policies, worked with lots of security
experts, been on several security courses, yada yada.  I don't recall ever
having seen this (a non-suid, world-executable binary) being checked by a
scanner, or forbidden by policy.  I'm only a single data point, but I'd be
really surprised if this was "common" in the general UNIX security
community.  Perhaps I've been isolated from sites governed by dumb-ass
managers.  If that's the case, I don't like solutions purely to satisfy
dumb-ass managers.

> you can also argue that it's part of a 'least possible permissions'
>  sort of thing where only the users/groups that _Need_ to run the
> programs/scripts have perms to do it, reducing the potential exposure
> if a security flaw is uncovered at some point in the future.

In most realistic scenarios, restricting access to a binary doesn't prevent
its execution.  Someone simply copies it from elsewhere.  If you can get a
login shell on a box, you can generally create any binary you want, and use
chmod to make it executable.  In this specific case, I don't even need the
Xymon binaries to be installed to send bogus reports to the server, if I
have a login on the client.  So what's the point?

The 'least possible permissions' policy is to be applauded in general, but
if it generates policy or procedures that don't actually restrict the bad
actors while making things difficult for the good actors, then it's being
implemented without using a threat model.  Being able to manually run
xymoncfg, for example, to diagnose a problem or misconfiguration is helpful
to a sysadmin.  Preventing this makes things harder for a sysadmin, but
doesn't actually stop him, or the bad guys.

I really can't see any practical benefit in altering the permissions of
these files, yet I can see it being a hindrance in some situations.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20130308/11dde44e/attachment.html>

More information about the Xymon mailing list