SoC: Improve syslogd

Hello,
I am preparing a Summer of Code application and would like
to introduce 
my project and myself, hoping for some feedback and advice.

I want to implement the upcoming IETF standards for Syslog 
(http://tools.ietf.or
g/wg/syslog/). In order of priority: 
syslog-transport-tls, syslog-protocol, and syslog-sign.

- transport-tls defines the network protocol to send syslog
over TLS 
(instead of UDP), thus providing a reliable and
authenticated transport.
In addition to reliable network transport I also consider a
modified 
local log submission (from syslog(3) to syslogd) to use a
stream instead 
of a datagram socket, thus providing reliable submission and
possible 
rate limits.

- syslog-protocol defines a new layout for syslog lines; the
most 
important additions are full timestamps (with year and
timezone) and 
structured data with name=value pairs. This enables all
programs to 
declare semantic content (uid, client IP, return codes, etc)
so an 
automatic log-monitoring only has to know the used namespace
instead of 
all possible messages.

- syslog-sign defines signature messages for authentication,
integrity 
and correct sequencing of syslog messages. (For this part I
am going to 
build upon the afaik only existing implementation by Albert
Mietus.)

To my knowledge that would be one of the first
implementations of these
protocols (which hopefully will be published as RFCs this
summer). It 
will provide NetBSD (and probably the other BSDs as well)
with an 
advanced, reliable, and secure syslogd, saving admins the
time and 
effort to install packages and set up custom logging
solutions just to 
get secure transport to their central logserver.

A little about myself: I study computer science at the
University of 
Potsdam, Germany. Beside my studies I administer some
FreeBSD servers 
and have already set up a logging infrastructure using
syslog-ng and 
stunnel, resulting in a talk about Logging at the Chemnitzer
Linuxtage 
2007 (german only).

Regards,
Martin

On Wed, 26 Mar 2008, Martin Schütte wrote:
> - transport-tls defines the network protocol to send
syslog over TLS (instead 
> of UDP), thus providing a reliable and authenticated
transport.
> In addition to reliable network transport I also
consider a modified local 
> log submission (from syslog(3) to syslogd) to use a
stream instead of a 
> datagram socket, thus providing reliable submission and
possible rate limits.

"a stream"? System V STREAMs are not available in
NetBSD AFAIK, or what 
exactly do you mean?


> - syslog-sign defines signature messages for
authentication, integrity and 
> correct sequencing of syslog messages. (For this part I
am going to build 
> upon the afaik only existing implementation by Albert
Mietus.)

What license is that existing implementation under?

I cannot comment on the subject at hand itself. Seems
there's a pretty 
high "research / conquer new grounds" factor in
it.


  - Hubert

On Thu, Mar 27, 2008 at 10:00 AM, Hubert Feyrer
<hubertfeyrer.de> wrote:
>  I cannot comment on the subject at hand itself. Seems
there's a pretty
>  high "research / conquer new grounds" factor
in it.

The biggie, at least IMHO is Unicode support. While I
followed every
IETF move with rsyslog (in fact, I used it partly for
prototyping), I
was hesitant to include Unicode support. That has the
potential to
break many existing applications.

Also, the new log line format is something that can break
existing log
parsers, so one needs to be very careful about how it is
implemented.
Rsyslog, for example, support high-precision timetamps for
over three
years now, but the default is still at using the standard
low-res once
for good reasons. High-precision time stamps need to
specifically be
enabled, and (unfortunately) few have done so so far.

Rainer

Hubert Feyrer schrieb:
>> local log submission (from syslog(3) to syslogd) to
use a stream 
>> instead of a datagram socket, thus providing
reliable submission and 
>> possible rate limits.
> "a stream"? System V STREAMs are not
available in NetBSD AFAIK, or what 
> exactly do you mean?

I mean a local stream socket as created by
"socket(PF_LOCAL, SOCK_STREAM, 0)" --
instead of "socket(PF_LOCAL, SOCK_DGRAM, 0)",
which is traditionally used for syslog(3).

>> - syslog-sign defines signature messages for
authentication, integrity 
>> and correct sequencing of syslog messages. (For
this part I am going 
>> to build upon the afaik only existing
implementation by Albert Mietus.)
> What license is that existing implementation under?

It is (or was) an extension to FreeBSD's syslogd and is
licenced under a 
BSD licence with advertising clause.

Project page: http://so
urceforge.net/projects/syslog-sec/
Copyright: 
http://syslog-se
c.cvs.sourceforge.net/*checkout*/syslog-sec/syslog-sec/FreeB
SD-syslogd/COPYRIGHT

-- 
Martin

Rainer Gerhards schrieb:
> The biggie, at least IMHO is Unicode support. While I
followed every
> IETF move with rsyslog (in fact, I used it partly for
prototyping), I
> was hesitant to include Unicode support. That has the
potential to
> break many existing applications.

Indeed. Having Unicode in logfiles also requires all used
shell tools 
and parsers to handle it correctly.

> Also, the new log line format is something that can
break existing log
> parsers, so one needs to be very careful about how it
is implemented.

The usual transition problem: noone uses the format -->
no parsers, and 
no parsers --> noone uses the format.

Apart from that I would think users with centralized logging
or 
automatic analysis would be the first to appreciate the
enhanced format; 
while desktop users who check their logs manually simply do
not care if 
the lines look a bit different.
Since the new format (-protocol) is a real superset, It is
also easy to 
provide a filter (a sed or awk command to re-format) for
compatibility.


Another problem is the API and the handling of structured
data 
(name=value-pairs).
I expect all applications to build their own structured
data-strings and 
pass them as messages to syslog(3), just to be portable. --
Thus a 
syslog library which modifies the structured data (to insert
additional 
information) will have to parse every message. :-/
In the long term it would be nice to introduce a new API
call which 
receives the structured data as a seperate argument.

-- 
Martin

On Thu, Mar 27, 2008 at 4:12 PM, Martin Schütte
<listsmschuette.name> wrote:
> Rainer Gerhards schrieb:
>
> > The biggie, at least IMHO is Unicode support.
While I followed every
>  > IETF move with rsyslog (in fact, I used it partly
for prototyping), I
>  > was hesitant to include Unicode support. That has
the potential to
>  > break many existing applications.
>
>  Indeed. Having Unicode in logfiles also requires all
used shell tools
>  and parsers to handle it correctly.

Having unicode in the syslog spec does not necessarily mean
that it
also needs to be persisted to log files. One approach may be
to accept
it as is and then convert it to whatever local charset you
intend to
have. So the end result inside the logfiles will be local
script, just
as is today.

I forgot to mention one thing that needs to be looked at:
syslog-protocol permits NULs to be present inside the MSG.
It has some
provisioning that permits a syslogd to remove/modify them,
but that,
of course, affects syslog-sign. NULs are quite problematic
in all
syslog code I have seen ;)

>
>  > Also, the new log line format is something that
can break existing log
>  > parsers, so one needs to be very careful about
how it is implemented.
>
>  The usual transition problem: noone uses the format
--> no parsers, and
>  no parsers --> noone uses the format.
>
>  Apart from that I would think users with centralized
logging or
>  automatic analysis would be the first to appreciate
the enhanced format;
>  while desktop users who check their logs manually
simply do not care if
>  the lines look a bit different.
>  Since the new format (-protocol) is a real superset,
It is also easy to
>  provide a filter (a sed or awk command to re-format)
for compatibility.

I like the idea with the filters. That's probably a solution
to the issue.

>  Another problem is the API and the handling of
structured data
>  (name=value-pairs).
>  I expect all applications to build their own
structured data-strings and
>  pass them as messages to syslog(3), just to be
portable. -- Thus a
>  syslog library which modifies the structured data (to
insert additional
>  information) will have to parse every message. :-/
>  In the long term it would be nice to introduce a new
API call which
>  receives the structured data as a seperate argument.

The right course of action, IMHO, is to provide the
underlying
infrastructure and then approach the glibc folks with a new
syslog
call. It's not something that is hard to do, but it requires
a lot of
community consensus - and the (near-) universal availability
of
syslogds that understand the format.

Rainer