[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
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...
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
This will be fixed in initscripts-5.45-1.