LWN.net Logo

The Journal - a proposed syslog replacement

The Journal - a proposed syslog replacement

Posted Nov 20, 2011 2:54 UTC (Sun) by THe_ZiPMaN (subscriber, #27460)
In reply to: The Journal - a proposed syslog replacement by quotemstr
Parent article: The Journal - a proposed syslog replacement

Who did say you cannot use text format?
You could even use standard syslog with only one minor change; it's enough to add at the end of the line another piece of text with the hash computed concatenating the syslog line with the hash of the previous line.

line 1: Timestamp1 Message1 Hash(line1 + salt)
line 2: Timestamp2 Message2 Hash(line2 + hash1)
line 3: Timestamp3 Message3 Hash(line3 + hash2)
line 4: Timestamp4 Message4 Hash(line4 + hash3)
...

3 years ago, in Italy, a new discussed law required to guarantee the integrity of the logs, and at that time I started to write a patch for rsyslog to implement exactly the above schema. The law wasn't approved in that way so I abandoned the develop of such thing, but it's not too complicated to write it.


(Log in to post comments)

The Journal - a proposed syslog replacement

Posted Nov 20, 2011 6:51 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]

one interesting issue with using a hash like this (both your proposal and the journal proposal) is that it will cause problems when logs get sent over the network.

the logs may end up arriving in a different order than you sent them for a number of reasons (UDP messages can pass each other on a network, you coudl send some logs to a relay box that fails before it re-sends them and the backup relay box sends newer logs on first, etc)

also if you are combining logs from many systems on one box, the you now have many different hash chains to track (and things get even more fun if you have more than one server sending with the same ID, something that happens in real life, even though it's a really bad idea)

The Journal - a proposed syslog replacement

Posted Nov 20, 2011 14:04 UTC (Sun) by THe_ZiPMaN (subscriber, #27460) [Link]

No, that's not the case because you are mixing 2 different problems.

Syslog already allows for secure, autenticated and reliable network communications, particulary using the RELP protocol (rfc 3195), so ther's no need to add an overhead to that phase.

The hash is then added only when the message is saved on the disk, non before sending it over the network. It's scope is only to guarantee that the log has not been modified after being written, not to guarantee it's immutable during network paths.
A "continuous hashing" calculated on a per file basis (or per DB if you prefer to save data in a database) is a possible cheap solution to this problem.

The solution is not complete as a journal, but it's really really simple to add to existing daemons (rsyslog and syslog-ng), does not require any invasive operation on the syslog infrastructure, allows a complete backward compatibility and satisfy a big part of the problem addressed by journal in a simple.

The Journal - a proposed syslog dropout?

Posted Dec 1, 2011 17:06 UTC (Thu) by gvy (guest, #11981) [Link]

It's weird that neither msyslogd or the preceding ssyslogd are even mentioned -- it's much better to reinvent the wheel at least knowing of prior art, /and/ to criticize the process thereof either. :)

Thanks Solar Designer, here's the link (in Russian).

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds