I just don't see the problem really with having a script inside /root/bin, which is completely locked down to only the root user, which parses logs via a cron job. I just don't see the harm.
I would have to concur on this. Only a user who has hijacked the root account will be able to mess with this script.
Let's say there's a deliberate back-door in, let's say, bash, so that whenever the input buffer has "xyzzy ..." in it, there's a vfork and ... gets passed to the child shell instance. That kind of string would be easy to get into a log file. Http agent strings, for instnace, can be anything. The problem is eliminating possible ways to hijack the root account. Log data is tainted. By tainted I mean that it can have arbitrary stranger-provided data in it. If the log cooking system runs as a non-root user, an exploit in log data (which might not be possible -- if all the logs contain is internally generated statistics and error messages, no externally provided texts, than this particular scenario would not apply -- could lead to a root breach.
This scenario is also an argument for centralized log processing; which standard syslog facilities provide OOTB, but I for one have never seen them actually set up.
Anyone else on this list actually doing network syslogging to a central log server?