| |||||||||||||
The Journal - a proposed syslog replacementThe Journal - a proposed syslog replacementPosted Nov 21, 2011 14:28 UTC (Mon) by nix (subscriber, #2304)In reply to: The Journal - a proposed syslog replacement by gmaxwell Parent article: The Journal - a proposed syslog replacement
It's the most recent entry the confirms the ones before it.That's pretty much useless. Given that POSIX doesn't provide an API for inserting text in the middle of files, someone buggering the logs has to read() and re-write() all the data from the buggered point onwards (and is more likely to just copy-and-rewrite the whole file, for simplicity: it's not like the log buggerer is likely to care much about performance). At best you'll get a read() of the end of the log followed by a truncate() and re-write(). But if you do that, you're rewriting the end of the log anyway, so you can update all the hashes at the same time. The only way this will ever be secure is if the hashes are stored separately from the logs, streamed immediately over the network and stored on a non-connected box running a daemon which can answer the question 'what is the hash of message N' and 'what is the hash of the message immediately preceding message N'. But there is no sign of such a scheme in journald: its design appears to militate against it much more than a straight-text logfile does, since you can rely on offsets in the latter remaining unchanged (so that an external file can point into them).
(Log in to post comments)
The Journal - a proposed syslog replacement Posted Nov 21, 2011 15:47 UTC (Mon) by johill (subscriber, #25196) [Link]
This is an important observation -- I thought about this too (but never posted), especially wrt. the comparison they make to git. The thing is this though: in git, the HEAD is essentially recorded at many places around the world -- rewriting the tree will be detected by everybody. In a journal, such a forward-running checksum scheme is completely useless as you point out since nobody has a copy of the HEAD sha1sum.
Looks like either we're not being told the full picture or somebody got confused about why exactly this useful in git.
(To make it secure though you don't need to store *all* hashes elsewhere, you just need to send off the most current HEAD hash to secure storage, still the same problem though.)
The Journal - a proposed syslog replacement Posted Nov 21, 2011 15:50 UTC (Mon) by johill (subscriber, #25196) [Link]
I note that they do say this though in their document, albeit a bit veiled (and the comparison to git was only made at KS I guess): "If the top-most hash is regularly saved to a secure write-only location, the full chain is authenticated by it."
It doesn't seem likely that anyone will ever have as easy ways to do that as with git.
The Journal - a proposed syslog replacement Posted Nov 22, 2011 4:26 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Actually, you're on the right track!
Make a central PUBLIC server that simply accepts and stores triples of form: <host_id, timestamp, hash> (host_id is UUID).
That's it. You can use this public server to periodically send your hashes. You lose (almost) no privacy, since log messages themselves need not to be replicated.
|
|||||||||||||