[2845] in SIPB-AFS-requests
replaced syslogd on sipb server machines
daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Fri Aug 29 04:56:08 1997
From: mhpower@MIT.EDU
To: usenet@MIT.EDU, rtfm-maintainers@MIT.EDU, webmaster@MIT.EDU,
anxiety-maintainers@MIT.EDU, charon-maintainers@MIT.EDU,
sipb-afsreq@MIT.EDU
Date: Fri, 29 Aug 1997 04:55:37 EDT
Because of recent description of exploiting syslogd vulnerabilities
posted to bugtraq by Yuri Volobuev, I've replaced the syslog daemon
on all of sipb's server machines. The new version is based on the
zephyr syslogd code from the zephyr locker, with a few changes
including support for a '-L' option that causes syslogd to ignore any
data sent to udp port 514.
Currently, the syslog daemon is running with the '-L' option on all
sipb server machines other than charon. There is no restriction on
remote logging to charon, which is supposed to handle some syslog data
from the sipb afs servers and meadow-p.mit.edu, and possibly handles
syslog data from some small number of office workstations. Potentially
this can be changed especially if there's a syslog attack on charon.
I didn't bother to support the filename /etc/nsyslog.conf. Instead,
on the Ultrix server machines, /etc/syslog.conf was renamed to
/etc/syslog.conf.ultrix, and then /etc/syslog.conf became a hard
link to the existing /etc/nsyslog.conf file.
It's possible that some Ultrix software, such as timed, ought to be
recompiled so that uses the correct syslog client code.
I left the names of syslog-daemon binaries as they were. Some are
/etc/syslog, some are /usr/etc/syslogd, one is /etc/athena/syslogd,
and one is /usr/local/etc/syslogd.
/afs/sipb/service/logging/src/zephyr/clients/syslogd/syslogd.c has the
modified source code. (The volume service.logging was created to hold
any software related to gathering or processing logs on sipb server
machines; at present it intentionally contains a complete build of
zephyr for Solaris, SunOS, and Ultrix.)
Changes other than support for '-L' are:
-- on Solaris where STREAMS_LOG_DRIVER is defined, it appeared
to jhawk and I that memchr probably was looking at the wrong
amount of data. It now looks at a different amount of data.
-- if the data read from the device file or udp socket contains
internal NUL characters, they are replaced with backtick
characters so that the post-NUL data isn't subsequently lost.
Supposedly internal NUL characters occur on Linux and are
part of the motivation for the printchopped function in the
Linux syslogd. I haven't yet attempted to generate data with
internal NUL characters to see whether this is an actual problem
on non-Linux systems.
-- the amount of data read is now always "sizeof(line) - 1" instead
of sometimes being MAXLINE and sometimes "sizeof(line) - 1"
-- the behavior of logging '\t' and '\n' was changed to match NetBSD
-- the error message is now included in what is logged by logerror;
previously, the entire error message was always discarded
-- a possible buffer overflow when reading the conf. file is avoided
Matt
