Bug 15979 - if '/' immutable set minilogd steals /dev/log: NO SYSLOG, DANGER WILL ROBINSON
Summary: if '/' immutable set minilogd steals /dev/log: NO SYSLOG, DANGER WILL ROBINSON
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rootfiles
Version: 6.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-08-11 11:18 UTC by Need Real Name
Modified: 2014-03-17 02:15 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2000-08-11 13:46:20 UTC
Embargoed:


Attachments (Terms of Use)

Description Need Real Name 2000-08-11 11:18:59 UTC
[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
"forever" 

(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
running.

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 13:46:18 UTC
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 16:19:00 UTC
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.