--BXVAT5kNtrzKuDFl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 24, 2006 at 06:03:32PM -0800, Jonathan Stone wrote:
> In message <20060325015117.GE11588@netbsd.org>Bill Studenmund writes
>=20
> >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 (large=
r)
> >system. Examining one system is easier than many.
>=20
> 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=20
only person I've seen mention "kauthd."

> >Yes, things get complicated when we're comparing a new larger single=3D
> >system to one multiple older ones.
>=20
> >From a security perspective: Complexity is bad.

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

> [...]
>=20
> >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.
>=20
> 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?)
>=20
> 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=
=20
as you are.

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

As for monotonicity, there are a few things that can be done. I think the=
=20
simplest is that there is a bit that controls the administrator's ability=
=20
to change bits to their less-secure setting. Set that to the can't-go-=20
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. :-)
>=20
> 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=20
this way.

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

Take care,

Bill

--BXVAT5kNtrzKuDFl
Content-Type: application/pgp-signature
Content-Disposition: inline

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

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

--BXVAT5kNtrzKuDFl--