Re: Vulnerability in 4.4BSD Secure Levels Implementation

[newsham () LAVA NET (Tim Newsham)]

> 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
> semantics.

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
> > obvious alternative.
>
> 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
secure-level construct?

> Niall

                                                    Tim N.