mailing list archives
Re: Vulnerability in 4.4BSD Secure Levels Implementation
From: newsham () LAVA NET (Tim Newsham)
Date: Sun, 28 Jun 1998 17:42:12 -1000
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
Yes there is.
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.
I didn't say anything about the system when it is powered down. I
can come up with better security systems for powered down systems :)
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?
Well, for example, the current secure levels system.
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.
And you expect it to protect the system logs after an intrusion has
occurred? Do you think that this is an attainable goal using the
- Solaris 2.6 non-executable stacks, (continued)