<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <p>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.</p>
    <p>Moving on, let's ACTUALLY LOOK at the logfetch man page, shall
      we?</p>
    <p><b>logfetch</b> 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.
    </p>
    <p>
      logfetch uses a configuration file, which is automatically
      retrieved from the Xymon server. There is no configuration
      done locally. <br>
    </p>
    <p>    So... It has to be configured... FROM the server and it comes
      with this warning:</p>
    <p>
      Do <b>NOT</b> install logfetch as suid-root. <br>
    </p>
    <p>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. <br>
    </p>
    <p>In fact, logfetch will
      attempt to remove its own suid-root setup if it detects that it
      has been installed suid-root.
    </p>
    <p><br>
    </p>
    <p>While you point out that out of the box it's not configured
      --noexec... Out of the box, it's not configured at all! <br>
    </p>
    <p><br>
    </p>
    <p>So it's kind of up to the admin to:</p>
    <p>a.) Actually turn it on <br>
    </p>
    <p>and <br>
    </p>
    <p>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.</p>
    <p><br>
    </p>
    <p>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.</p>
    <p><br>
    </p>
    <p> <br>
    </p>
    <div class="moz-cite-prefix">On 6/8/21 1:12 PM, John Thurston wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:c219d50e-2a9f-e97c-7d58-8a8e81fc1a93@alaska.gov">
      <br>
      On 6/8/2021 11:49 AM, Bruce Ferrell wrote:
      <br>
      <blockquote type="cite">  Are you
        <br>
        maybe referring to remote logfetch via ssh?
        <br>
      </blockquote>
      <br>
      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).
      <br>
      <br>
      Per the man page:
      <br>
      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
      <br>
      <br>
      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?
      <br>
      Why would anyone want to permit this?
      <br>
      Do you still use 'telnet' for production job control?
      <br>
      <br>
      <br>
      <blockquote type="cite">My point is that simple is good.  Simple
        is in your control.
        <br>
        <br>
        Your point John?
        <br>
      </blockquote>
      <br>
      My point is that a 'simple solution' may not include some things
      which have become standard and expected between 1998 and 2021.
      <br>
      <br>
      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.
      <br>
      <br>
      <br>
      --
      <br>
      Do things because you should, not just because you can.
      <br>
      <br>
      John Thurston    907-465-8591
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:John.Thurston@alaska.gov">John.Thurston@alaska.gov</a>
      <br>
      Department of Administration
      <br>
      State of Alaska
      <br>
      _______________________________________________
      <br>
      Xymon mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:Xymon@xymon.com">Xymon@xymon.com</a>
      <br>
      <a class="moz-txt-link-freetext" href="http://lists.xymon.com/mailman/listinfo/xymon">http://lists.xymon.com/mailman/listinfo/xymon</a>
      <br>
    </blockquote>
  </body>
</html>