Yes, john, you're right... Things have changed on 20 years. But even 20 years ago capable admins only exposed what needed to be exposed. Some exposed everything to the raw internet.? Did you do that then? ? I know I don't now and never did.? I knew better but some call me a control freak too.
Moving on, let's ACTUALLY LOOK at the logfetch man page, shall we?
*logfetch* is part of the Xymon client. It is responsible for collecting data from logfiles, and other file-related data, which is then sent to the Xymon server for analysis.
logfetch uses a configuration file, which is automatically retrieved from the Xymon server. There is no configuration done locally.
??? So... It has to be configured... FROM the server and it comes with this warning:
Do *NOT* install logfetch as suid-root.
There is no way that logfetch can check whether the configuration file it uses has been tampered with, so installing logfetch with suid-root privileges could allow an attacker to read any file on the system by using a hand-crafted configuration file.
In fact, logfetch will attempt to remove its own suid-root setup if it detects that it has been installed suid-root.
While you point out that out of the box it's not configured --noexec... Out of the box, it's not configured at all!
So it's kind of up to the admin to:
a.) Actually turn it on
and
b.) Assure it's been secured for noexec... It already makes an attempt to protect itself from suid stuff if it can and thereby protect against arbitrary commands.
But that kind of applies to any installation doesn't it?? And I know I get kind of testy when someone who doesn't know my system attempts to override my management.
On 6/8/21 1:12 PM, John Thurston wrote:
On 6/8/2021 11:49 AM, Bruce Ferrell wrote:
? Are you maybe referring to remote logfetch via ssh?
I am referring to logfetch, which is part of the standard client package, and which does not default to -noexec (and which does not use ssh).
Per the man page: Logfetch can be requested to execute arbitrary commands to generate a list of log files to examine dynamically, but this can present a security risk in some environments. Set this option to prevent logfetch from executing requested commands
Let's pass arbitrary code, unencrypted across the network, for it to be run by a daemon on a remote machine. What could possibly go wrong? Why would anyone want to permit this? Do you still use 'telnet' for production job control?
My point is that simple is good.? Simple is in your control.
Your point John?
My point is that a 'simple solution' may not include some things which have become standard and expected between 1998 and 2021.
I still run Xymon, and have been running its predecessors since the late 90s. But this _is_ 2021. Encrypted network communication, or at least the _capability_ to encrypt network communication is pretty much normal. When my users come to me asking me to make Xymon do things for them, I must continually remind them of its 1990's roots, and clarify which of their base assumptions may not be valid.
-- Do things because you should, not just because you can.
John Thurston??? 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon