Bug 10222 - /dev/log permits anyone to forge arbitrary audit records
Summary: /dev/log permits anyone to forge arbitrary audit records
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: sysklogd   
(Show other bugs)
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2000-03-17 15:35 UTC by David A. Wheeler
Modified: 2014-03-17 02:13 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-18 15:36:53 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description David A. Wheeler 2000-03-17 15:35:36 UTC
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[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".

Comment 1 Nalin Dahyabhai 2000-03-17 18:47:59 UTC
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.

Comment 2 Nalin Dahyabhai 2000-03-17 20:03:59 UTC
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.

Comment 3 Nalin Dahyabhai 2000-04-05 20:26:59 UTC
Changing the permissions will break many programs, so syslog needs to be able to
distinguish between various users who send it data.

Comment 4 Andrew Bartlett 2000-11-11 08:43:32 UTC
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

Comment 5 Bill Nottingham 2001-01-19 18:08:17 UTC
As for the last selection, no. Programs run as arbitrary users still
need to be able to call syslog().

Comment 6 Andrew Bartlett 2001-03-31 12:14:21 UTC
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?

Comment 7 Alan Cox 2002-12-14 22:09:05 UTC
Newer kernels have socket options to get the peer information - so it is now
possible to log this data I think

Comment 8 Josh Bressers 2004-06-18 15:36:53 UTC
Closing; This issue was fixed a while ago.

Note You need to log in before you can comment on or make changes to this bug.