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
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
logger -p authpriv.none "PAM_pwdb: (su) session opened for user root
logger -p authpriv.none "PAM_pwdb: (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
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.