Why do you think that it is necessary to modify the established log file format. The features described here can be kept in their own tracking file maintained by the syslog system without a single modification to any of the existing files or formats. If people do not want this performance wasting feature then they can do without. I haven't seen a wide spread problem with these log files. Hardened systems track entry in multiple ways using redundancy and isolation in security mechanisms. They try to avoid single-points of failure whenever possible. It has been suggested that log files were modified to hide the tracks of hackers but how often have they succeeded? They didn't in the case mentioned since they got caught.
Security is a constantly changing field so vulnerabilities like these have to be examined. But we have to consider the impact on performance. Generating hash codes is not a simple or quick operation when you are considering it in relation of a heavily used transaction processor. Hash codes on the syslog may not noticeably impact a low demand but it will never be used on a high-demand server.
In any case, I am against use of binary files for system administration of UNIX/Linux systems. Human readable ASCII files preserve compatibility, make it easier for system operators to tell what is going on, and make it easier for new users to learn how the systems work. What do you do when you binary log reader is hacked? How can you tell the difference when it is telling you the truth or is lying to you?
Posted Nov 19, 2011 12:16 UTC (Sat) by intgr (subscriber, #39733)
[Link]
> Generating hash codes is not a simple or quick operation when you are
> considering it in relation of a heavily used transaction processor.
Nope, that's premature optimization.
I'm sure the Journal system will introduce new performance bottlenecks, but hashing is not one of them. Even my 2-year-old CPU (Phenom II) can hash ~300 MB/s of data per second with SHA-512, on a single CPU core. SHA-1 and MD5 are even faster.