From: Bill Studenmund (wrstudennetbsd.org)
Date: Mon Mar 27 2006 - 19:52:21 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Fri, Mar 24, 2006 at 06:03:32PM -0800, Jonathan Stone wrote:
> In message <20060325015117.GE11588netbsd.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.

Then I strongly encourage you to re-read them. For starters, you are the
only person I've seen mention "kauthd."

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

Uhm, how does that statement follow? If you'll read my sentance carefully,
you'll see I'm discussing the complexity of discussion. Not the complexity
of either system.

> [...]
>
> >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.

It is not clear to me that Thor is reading the discussion exactly the same
as you are.

Well-defined, do you really have to ask that one? We define what gets
disabled at different securelevels (well, this really means making sure
the documentation and code match). We visually inspect the bitmap in the
compat code, and make sure it asserts the same settings. We inspect the
code to make sure the old users of securelevel to ensure they make correct
adjusted calls.

As for monotonicity, there are a few things that can be done. I think the
simplest is that there is a bit that controls the administrator's ability
to change bits to their less-secure setting. Set that to the can't-go-
back setting, and you have monotonicity.

> >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
> here??

Probably because the folks with the energy to implement this want to go
this way.

And it most certainly is happening with discussion. As evidenced by these
notes. :-)

Take care,

Bill

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFEKJbVWz+3JHUci9cRAqoLAKCWwqjspSQWaVXuDTua3LAHmgbf0wCeM2m9
nFI0Hi8y/upUVYoMA4BKmgA=
=8NsT
-----END PGP SIGNATURE-----

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]