Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 15979 - if '/' immutable set minilogd steals /dev/log: NO SYSLOG, DANGER WILL ROBINSON
if '/' immutable set minilogd steals /dev/log: NO SYSLOG, DANGER WILL ROBINSON
Product: Red Hat Linux
Classification: Retired
Component: rootfiles (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Depends On:
  Show dependency treegraph
Reported: 2000-08-11 07:18 EDT by Need Real Name
Modified: 2014-03-16 22:15 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-08-11 09:46:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2000-08-11 07:18:59 EDT
[incorrectly assigned to rootfiles by ignorance of component and
inflexibility of 'Component Text' field, please reassign if nccy]

Doing 'chattr +i /' has an odd, unwelcome result:

1. breaks logging after next 'init.d/syslogd restart'

2. results in minilogd listening to '/dev/log' and swelling pregnant buffer

(I didn't check this, but) if minilogd has a mem ulimit or buff size limit
it may later die with logging still broken... but if not, the stored syslog
buffer may eventually swab swap and panic the system (?)


On startup, minilogd does an access('/') -- perhaps to decide whether the
system is running at a boot step prior to the r/w mounting of '/'

If '/' is not writeable for any reason, minilogd then directly proceeds to
unlink and link /dev/log, and parks waiting for messages.

Perhaps it base that assumption directly on access('/dev/log') instead...?
If the system has not yet mounted root-fsys rw the socket would also fail
the test.

There may exist a scenario where a attacker script may "chattr +i /dev/log;
killall syslogd" ... I leave the task of effect and possible check &
countermeasure to more devious people with better brains...

>>> In this instance it also does not check to see if syslog is already

I set immutable on '/', and some other directories and files, which seemed
a prudent precaution to take to thwart possible script kiddies running
rootscripts that are not chattr-aware... or perhaps protect against the
ability to trick a suid program into writing as root on/into a critical
file or directory... though I admit ALSO as slippery-finger insurance for
crosseyed su infested operators ;) ...

Upon next syslogd restart, logging stops and does not resume: as part of
the deep '/etc/rc.d/init.d/syslog restart' sequence, initlog runs minilogd
which -- upon the fail of access('/') -- diverges from its usual course...
unlinks /dev/log out from under the running syslogd, which is still ready
to log something but does not notice that it is now listening on an
orphaned inode... minilogd parks and sucks /dev/log for all eternity...
Comment 1 Bill Nottingham 2000-08-11 09:46:18 EDT
This is *not* a security bug. If an attacker gets enough privelege
to modify /dev/log, he can do so many other things that it's rather
pointless to worry about this particular case.

Still, the 'start daemon' algorithm does need fixed; we'll look
into it.
Comment 2 Bill Nottingham 2000-08-11 12:19:00 EDT
This will be fixed in initscripts-5.45-1.

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