Re: Living with today's syslog (sorry for garbled prior msg...)

[by way of "Chris M. Lonvick" <[EMAIL PROTECTED]>]

Darren Reed <[EMAIL PROTECTED]> wrote: "... documenting the
protocol used by syslogd from (say) 4.4BSD..."

4.4BSD syslog.h and syslogd is probably the right one, but I understand
that security problems with syslogd have shown up in different forms in
different implementations.  I myself am not fully informed about the
history of such problems, and I'd hope we can briefly catalog them in the
RFC.

More important, the security threat model should be described clearly so
that it's clear which attacks are most important (internal vs external, DoS
vs spoofing, root permission via stack overflow vs killing daemon via stack
overflow, etc. etc.).  This involves a lot of experience and judgement
about risk and defense.   My hope is that this initial RFC could list
recommended practices for network log client devices and the network
portion  of the syslogd interface, so that some of these risks can be
moderated even with the current population of syslogd implementations.
Some of these recommendations might taken from _Firewalls and Internet
Security_ by Cheswick and Bellovin, who talk a lot about logging in
firewall defense but less about log record vulnerability, other than the
vulnerability of a log file in a hacked system, that Schneier's paper
discusses.


That population should be upgraded to a "syslog2" replacement, which is
under discussion here, but it certainly won't happen quickly.

"I get the impression that you'd also
like to see that document cover the addition (and format) of syslog
messages
which contain MAC's.  Is this what you're pushing for here ?  If not, I've
no issue, but otherwise there is potential for a lot of other `hacks' to
be included..."

Use of authentication MACs in the message text is one obvious suggestion
that I made, because it's quick and cheap and reuses existing library code,
and so can be quickly supported as an optional feature in most existing
network devices.   I'm sure there are others.  This is in no way intended
to minimize the need for a syslog protocol replacement -- your work among
others is extremely important here.

It sounds like I should draft the informational RFC to get my suggestions
recorded.  I'll try to do that this weekend.

Alex