Anonyma wrote:
> Anonymous wrote:
>
>> Bearing in mind the issues:
>>
>> [http://www.redteam-pentesting.de/adv...a-2005-15.txt]
>>
>> AND Theo's attitude ,
>>
>> "Sorry, we are going to change nothing. Securelevels are useless."
>>

>
> Clever Monkey wrote:
>
>> ...and notice that neither of the other platforms had anything better to
>> say on the matter. Clearly no one is going to fix this broken model.
>> Theo is just not bothering to sugar-coat it.

>

[...]
> *** There is "sugar-coating" and there is defeatism.
>

Read this:

The conclusion of the article: Theo is probably right, but didn't say it
the right way.

If I had a dollar for every time Theo said something that offended
someone, I'd have a few bucks in my pocket. I could buy some doughnuts.

So, yes, other vendors are sugar-coating this problem, because
securelevels is a hack and everyone else wants to say "Due to inherent
weaknesses with the securelevel system, securelevels will not be
included or maintained in any future release of [%product_name%] blah
blah blah." Theo prefers his pills bitter, I guess. If Theo was the
CEO of a publicly traded company and I was a share-holder, I'd slap him
for saying this. Since he's not, he's free to say as pleases.

Here's my understanding of the problem:

Since it does no harm to leave securelevels in (other than a false sense
of security when used even if this local hole did not exist), and incurs
all sorts of risk to tear them out (it is always risky to change things,
and I assume that these are kernel things that need changing), it is up
to the admin to follow good security policies and use the tools at their
disposal.

Should OpenBSD plug this (local) hole, where someone could "modify"
(actually, replace for the lifetime of the mount) immutable files?
Perhaps, but there is no proven vector for privilege escalation in
OpenBSD (according to the article you cite), which is usually a
threshold for security fixes in my experience.

This is not as cut and dry as you are making it out to be.

What would you rather use: a proven, modern tool like systrace or an
hacky afterthought like securelevels. Now that we have something that
replaces securelevels, the user base should be encouraged to move away
from it because it does not really do what it was designed to do.

This is true for Linux, OpenBSD, FreeBSD and NetBSD.

Bottom line: if you need real multi-user, multi-level security you
cannot rely on securelevels. Use the appropriate tool for the job.