Linux syslog on the way out?
itworld.com
Linux syslog on the way out?
1–10 of 46 posts
Re: Linux syslog on the way out?
#2On a compromised system you can't trust any file stored on the system. Be it text log files or binary log files. The person who compromised the system will just dump the entire binary store instead, which is normally what happens to text log files.
I use many commands (grep, tail, head, etc) to view and parse log files daily. And storing the files will just add complexity to a very simple system. Now I don't disagree that syslog needs some further advancements for access control/management. I may just be not thinking a head and what else could be possible; but I just see this interrupting my normal workflow for debugging issues.
Re: Linux syslog on the way out?
#3Do these guys even have an editor? From the article:
...nature of the syslog, which basically excepts text strings in whatever form the application...
...one daemon may send information about an even in one way, and another daemon in a completely different way...
Re: Linux syslog on the way out?
#4On a compromised system you can't trust any file stored on the system. Be it text log files or binary log files. The person who compromised the system will just dump the entire binary store instead, which is normally what happens to text log files. I use many commands (grep, tail, head, etc) to view and parse log files daily. And storing the files will just add complexity to a very simple system. Now I don't disagree…
Cryptography, properly applied, allows you to verify file integrity. The real problem becomes one of key management however -- if the Journal proposal solves this issue (and it's not a simple one) then it's possible that the "has the integrity of my system logs been preserved/maintained" question can be answered.
Managing keys properly is highly non-trivial, especially on a system in which you want those keys to be available/accessible automatically at boot. Since the proposal works via signing (hashing) rather than decrypting, PKI could be used, but I still smell issues.
Re: Linux syslog on the way out?
#5There is no method currently defined to forward logs to another machine, so the journal is definitely prone to a local attack wiping it out (you typically have to be root to wipe log files anyway). The only method mentioned to move logs off-system is scp or rsync or some other method of copying a file over the network, which, to me, is a non-starter. I keep logs both locally and forward them to a trusted host, just in case.
I'm neutral on the binary format of the log; I can see both sides of the argument.
Re: Linux syslog on the way out?
#6My first (shallow) read of the proposal is that it solves one relatively high-risk, low-probability case by throwing a great deal of complexity at standard operations on which a great deal of existing infrastructure exists: log analyzers, summarizers, rotation systems (broken as they may be), and just simple shell tools.
Immediately prior to launching myself into Linux, I briefly toyed with Windows NT 4.0 WS, and among the bigger disappointments of it was the system logging facility and its user interfaces. While *nix logging has its bugaboos, the ability to chain simple tools together to perform tasks (example: grep, cut, and uniq -c on a postfix logfile to give a per-hour summary of mail delivery status by various classifications) provides tremendous flexibility. As compared with the single GUI interface Microsoft provided. I'd hope that Poettering et al won't repeat this bone-headed mistake, but the simple observation that their sample log event lacks ... a date stamp??!!! ... doesn't inspire me.
If there's a useful element from this it's the list of horribles against current syslog weaknesses. Many of these could be addressed by amending syslog and/or providing a bolt-on solution. I don't see a need for a total replacement.
As to the observation that there are currently several (incompatible) logging systems on Linux systems, ob xkcd: http://xkcd.com/927/
Re: Linux syslog on the way out?
#7This is a waste of time. Syslog is the standard for logging on *nix. You will bork everything if you replace it with something incompatible. Everybody knows this. So whatever you replace it with must be Syslog compatible. If that's the case ... there are numerous alternatives to choose from. Like rsyslog. Which is already standard on RHEL, nevermind Fedora. Rsyslog has this nifty feature where you can immediately transfer all logs via TCP or UDP to another host. Hacking problem solved. Stop fixing things that aren't broken.
Re: Linux syslog on the way out?
#8If this means that syslog-ng is in the way in, great!
Re: Linux syslog on the way out?
#9Just because you make something "binary" does not mean it is inherently secure. As pointed out elsewhere, syslogd is a pretty reliable, simple and flexible foundational piece of infrastructure. Changing this with something un-tested and not entirely understood would, imho, be a Very Bad Thing(TM).
Re: Linux syslog on the way out?
#10On a compromised system you can't trust any file stored on the system. Be it text log files or binary log files. The person who compromised the system will just dump the entire binary store instead, which is normally what happens to text log files. I use many commands (grep, tail, head, etc) to view and parse log files daily. And storing the files will just add complexity to a very simple system. Now I don't disagree…
Cryptography, properly applied, allows you to verify file integrity . The real problem becomes one of key management however -- if the Journal proposal solves this issue (and it's not a simple one) then it's possible that the "has the integrity of my system logs been preserved/maintained" question can be answered. Managing keys properly is highly non-trivial, especially on a system in which you want those keys to be…
Cryptography allows you to verify that somebody who does not possess your private key did not modify the file. A hacker on the same system as a syslogger has the private key of the syslogger. They can "simply" (for varying values of simply) replay the logs again, only with whatever events they want filtered out or modified, and it will pass the crypto checks just fine. You have to offload your logs somewhere else, at which point the whole encryption in the logs themselves are sort of redundant.
Managing keys in this case isn't just "highly non-trivial", it's flat out impossible.