mailing list archives
Re: Vulnerability in 4.4BSD Secure Levels Implementation
From: njs3 () DOC IC AC UK (Niall Smart)
Date: Mon, 29 Jun 1998 00:47:00 +0100
On Jun 26, 8:41am, Tim Newsham wrote:
} Subject: Re: Vulnerability in 4.4BSD Secure Levels Implementation
- The syslogd daemon can be covertly compromised, so no useful
information ever gets logged to the protected system logs. But at
least no-one can modify the useless information.
Be smart, niall, syslog can only be compromised after the system
has been compromised.
Yes, obviously. How many exploits do you know of that generate log
entries as a side effect? Do you trust the program that you use to view
your logs? Get smart, tim.
McKusick et al have this to say:
Files marked immutable include those that are frequently the subject
of attack by intruders (e.g., login and su). The append-only flag
is typically used for critical system logs. If an intruder breaks
in, he will be unable to cover his tracks. Although simple in
concept, these two features improve the security of a system
Since the intruder cannot reverse time, he cannot cover his tracks
in the system log. Just as McKusick said! (wow, he must have known
about the time thing too!)
I don't see how you think monotomically increasing time source has
anything to do with the point I'm making, i.e., that there is no point
in "protecting" su or login with the immutable flag with the currentl
Why do they advocate protecting login and su if such protection can
be trivially defeated using the same techniques we demonstrated in
the attack on inetd? And why do they claim these features improve the
Because protecting login and su will protect the persistant system.
Yes, the running system may still be compromised. Securelevels does
not address that issue. (perhaps your stance could be summed up
as: "securelevels should protect the running system"?)
Well I'd like to think that all security measures should protect the
running system, powered down systems tend not to be very vulnerable.
Propogation of the immutable flag is the logical and correct thing to do.
I agree that this behaviour is not explicitly documented, however it
is a reasonable expectation that people hold. Secure levels become a
farce without it.
I can see why one might think this is desirable, but it's hardly the only
What are the other "obvious" alternatives?
I wouldn't call securelevels minus this feature a
"farce" (that is, if securelevels plus this feature isn't considered
a farce as well :)
Secure levels minus this feature are only useful for protecting system
logs generated during the intrusion. Thats crap.
- Re: Full Armor.... Fool Proof etc... bugs, (continued)