SDSC Secure Syslog

Wee writes "I saw this morning that the San Diego Supercomputer Center has released Secure Syslog, a replacement for the standard Linux/UNIX syslog daemon they've been working on for some time. It adds security and performance features (modular design, highly scalable), while retaining backwards compatibility. According to their announcement, it is the first syslog implementation to target "syslog-reliable" (RFC 3195) functionality and it is the first syslog targeted at very high performance and forensically-sound auditing. It's currently under the UC's "free for non-commercial use" license, but they are looking at moving to a completely open license (BSD-style licensing was mentioned). If you have high-traffic systems and you need reliable syslogging, this might be a worth a look. Those needing syslogging over TCP/BEEP, sockets, etc as well as UDP might also want to check it out."

Comments

TCP syslogging already available

[The Blue Meanie]

If you need syslogging over TCP and want a *way* more configurable system for filtering syslog destinations, including regex filtering and per-host routing, you might want to look at syslog-ng. It works great for me, and is already GPL'ed, so no waiting for a license change.

Brazil

[SWroclawski]

Wow did anyone else notice the Brazil references in RFC 3195?

It's good to know that geek culture still persists and can perimate into even the most serious subjects.

- Serge Wroclawski

Several problems with syslogd.

[defile]

Standard syslog has several problems which I think are quite serious.

• Remote logging is a joke. There is no authentication, and no notification whatsoever that the event was received by the remote syslog daemon. An attacker can fill the remote syslog with garbage data if they so choose.

• The records are entirely unstructured and not validated. The timestamp, hostname, and process id are all volunteered by the application, not something that's noted by syslogd.

• There is no guarantee whatsoever that an application that has called syslog() will have its messages safely recorded when the function returns. I'm not talking safely tucked away on disk if the system crashes, but even written into the buffer cache by syslogd when syslog(3) returns. See end of post for details.

• If syslog's receive buffer is full, syslog(3) will block. This means that if syslogd cannot keep up with the rate of messages, which is a really easy condition to find yourself in given that by default syslogd calls fsync() after every log file update, your system will slow to a crawl. You cannot even login(1) since most systems record this activity to security logs.

P.S. syslog() returns as quickly as possible. Try an experiment. Generate a random number, call syslog() with this number as a string, and then open() /var/log/messages, seek to the end minus 4096 bytes. Try to find the random number. I have tried it 20 times and never has the number been there by the time read() was called. It takes longer than an application doing syslog()/open()/lseek()/read() for syslogd to record it into to the buffer-cache, let alone fsync() it to disk.

An interesting extension of a lousy idea.

[Doktor Memory]

Although it's nice to see people attempting to improve one of the more regularly broken unix core services, I still think that the whole syslog design of a monolithic central multiplexed logging daemon is the Wrong Design.

Dan Bernstein's multilog, from his daemontools package, is, in my opinion, a good example of the correct way to do logging: a single process logs the stdout and stderr of each daemon, goes to great lengths to ensure that no data is lost, and handles logfile rollover automatically. With this tcpserver/tcpclient utilities from his ucspi-tcp package, it can be simply done over a network as well.

Of course, DJB's code, while source-available, is not in any way Free Software, and daemontools in particular currently is inextricably linked into his extraordinarily dubious "slashpackage" system, making it a potentially annoying choice for anyone reselling or distributing systems based on it. Cronolog, which was originally created to manage apache logs, looks like a promising GPLed replacement for multilog, but despite lots of grumbling along those lines, nobody has written a gpl/bsd replacement for daemontools...yet.