Greetings; I have a Red Hat 6.1 system which uses your sysklogd program version 1.3.31. I've found a security issue with sysklog's configuration. It appears that the default configuration on this system lets anyone write to /dev/log, e.g., ls -l: srw-rw-rw- 1 root root 0 Mar 6 10:54 /dev/log This means that any local user can forge any logged message they'd like. This can make it impossible for administrators to determine "what's really going on"; there's no way to know which messages are real and which are forged. I can forge a thousand break-ins... which ones occurred? Did any? Did I hide which one happened? Here's a trivial example: logger -p authpriv.none "PAM_pwdb[9999]: (su) session opened for user root by dwheeler(uid=500)" logger -p authpriv.none "PAM_pwdb[9999]: (su) session closed for user root" Obviously, this is not a "break-in" problem, but it is an audit log integrity problem. Simple solution: "chmod o= /dev/log".
Newer versions of logger from util-linux prepend the user's name to the log entry before sending it to syslogd, but this should really be fixed in syslogd.
Per private email, logger doesn't have any special privileges, and there's no way to fix this with the current syslogd while still making the logging facility available to everyone. Using a connected Unix-domain socket would let syslogd identify the UID/GID/PID of the sending process and impose limits that way, but this was changed to work around a DoS problem that cropped up a while back.
Changing the permissions will break many programs, so syslog needs to be able to distinguish between various users who send it data.
Could all users that need to log messages be placed in a special group 'log' with the respective changes on the /dev/log premissions? Such a solution would also require stopping access to syslog over the network (at least from the local computer) to avoid sombody just bypassing the permissions. (I don't mind network based syslog being fakeable, as long as it does not contain *my* hostname). Also it would be nice to make it impossible for a user to write kernel messages, or at least make sure syslogd gets its kernel input only from klogd, not joe-random-hacker.
As for the last selection, no. Programs run as arbitrary users still need to be able to call syslog().
This sounds like the job for a small sgid wrapper, which would verify its input as sane (correct timestamps, program names distinugised by username etc) and pass it onto the standard syslog. Is this at all possible? Or are the implications of yet another set-uid program not worth the bother?
Newer kernels have socket options to get the peer information - so it is now possible to log this data I think
Closing; This issue was fixed a while ago.