Subject: Re: Integrating securelevel and kauth(9)
To: Bill Studenmund <firstname.lastname@example.org>
From: Jonathan Stone <email@example.com>
Date: 03/24/2006 18:03:32
In message <20060325015117.GE11588@netbsd.org>Bill Studenmund writes
>I took his point as saying that the current code does a number of
>different things to deal with security considerations. The replacement
>code folds everything into one consistent framework. That goes directly to
>confidence; examine a number of different systems vs. examine one (larger)
>system. Examining one system is easier than many.
Bill, franlky, I couldn't see anything in Elad's reply except
deprecating statements about secureleve and praiseful statemnts of
kauthd; none of which are on-topic to my point.
>Yes, things get complicated when we're comparing a new larger single=
>system to one multiple older ones.
From a security perspective: Complexity is bad.
>> For me, and for Thor, the key feature is the ability to enforce
>> revocation, from *all* users or processes or whatever, *any* ability
>> to perform certian actions; and to be able to enforce such revocation
>> at certain well-defined points during system startup, and irrespective
>> of the prior ability of those users/groups/whatever. You may think
>> tha'ts a hack, but it's acutally a very useful tool for building hardened
>> secure systems.
>And it certainly can be done here, and probably should be. And it's not
>hard. Make kern.securelevel write-only and have setting different values
>set the bitmap as appropriate.
Huh? How does that emulate how Thor and I and others use securelevel?
How does it provide a well-defined, *monotonically-decreasing* set of
allowable operations? (Let alone doing so with high assurance?)
If you think I'm missing something, please do try to explain it; I see
Thor making exactly the same points, and so if I'm missing something,
Thor is missing it also.
>Further, while the implementation is new, my understanding is that it's
>implementing what Apple has done. So we aren't totally rolling our own
>security system. :-)
Err, and just why should NetBSD go blindly with a re-implemntation of
"what Apple has done", as opposed to other alternatives? (TrustedBSD,
SELinux, ... ?) And how and why is that happening, without discussion