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

On Fri, Mar 24, 2006 at 04:27:12PM -0800, Jonathan Stone wrote:
>=20
> In message <442487A6.1060000@NetBSD.org>Elad Efrat writes
> >jonathan@dsg.stanford.edu wrote:
> >
> >While I can certainly understand your concern, there is an aspect you
> >did overlook in my proposal. :)
>=20
> Elad, If you really think so, please point out what any specific
> item(s) you think I overlooked.  I ask because because I've read the
> paragraphs below three times now, and *NONE* of what you wrote
> addresses my point in any way whatsoever.  Perhaps you'd care to
> explain how any of the text below relates to the *INITIAL* confidence
> in your replacement code? Or to concerns, as per Thor's over whether
> it's an effective replacment for securelevels?

I took his point as saying that the current code does a number of=20
different things to deal with security considerations. The replacement=20
code folds everything into one consistent framework. That goes directly to=
=20
confidence; examine a number of different systems vs. examine one (larger)=
=20
system. Examining one system is easier than many.

Yes, things get complicated when we're comparing a new larger single=20
system to one multiple older ones.

> In fact, your comments makes me fairly confident that you haven't
> grasped my point at all.

I suggest caution regarding deciding someone didn't get your point. It=20
could always be s/he did and you didn't get the answer. I've done that=20
before. :-(

> >At the moment, the kernel has many ways for doing things that belong
> >in the same area: for example, some parts of the kernel call suser(),
> >other parts simply check for euid zero, others care about egid and
> >group membership. Securelevel is yet another interface in the kernel
> >for doing more-or-less the same things -- checking if an operation is
> >allowed or not given a certain system context.
> >
> >One of the benefits we get from using the kauth(9) framework is that
> >the code used across the kernel to do all those things, and more, is
> >centralized and contained. So even though it's "new" code that hasn't
> >been reviewed as much as the code it replaces, the process of reviewing
> >it is a lot easier for others.
> >
> >Instead of checking a single variable throughout the kernel, we hide
> >that internal detail from the kernel, and change all references to
> >issue a request for the requested privilege(s). The listener receiving
> >the request and its context can do whatever you want -- match it
> >against the securelevel variable, matching against the securelevel
> >bitmask, or even dispatch the request to a userland daemon to make a
> >decision. This is all hidden from the caller -- who's just interested
> >in knowing if it can do what it wants or not.
> >
> >To me, and I'm sure that to others as well, the BSD securelevel is just
> >a hack. Sure, it's a long-time reviewed hack that may come in handy to
> >do certain things quickly -- but it's still a hack, and as such, I think
> >that in the long-term we'll only benefit from replacing it, and other
> >parts of the kernel, with a consistent interface that is better
> >understood. (compare "if securelevel > 1" and "if this user can do this
> >operation")
>=20
> Elad: just which point of this do you think I overlooked?
> Just which part addresses my comments?
>=20
>=20
> All I can take from it is to begin to suspect that you haven't
> understood either my comment, or Thor's commment.  Being able to test
> on a fine-grained basis for
>=20
> 	"can this particular  user (or process) can do some particular operation"
>=20
> is *NOT*, repeat *NOT* a replacement for a system-wide knob which can
> forbids a monotonically-increasing set of operations to *ALL* users,
> irrespective of uids or inherited capabilities or ... whatever.

Jonathan, please don't shout.

In fact, I think you're wrong. It certainly can be a replacement for a=20
system-wide knob. To say if it is or isn't requires examining the=20
implementation.

> 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=20
hard. Make kern.securelevel write-only and have setting different values=20
set the bitmap as appropriate.

> The ability to enforce revocation, at specified points, is what Thor
> is getting at with his "run-level" suggestion.  You're of course free
> to denigrate the BSD-securelevel machinery by calling it a "hack"; but
> you're going to have to provide a suitable replacment if you want your
> proposal to be accepted as a substitute.
>=20
> And please don't offer these nebulous "kauthd" callbacks as a
> substitute, not until they've been well-audited and well-reviewed.

kauthd callbacks?

Also, how can the infrastructure be audited before it's offered? Elad=20
_has_ to offer the routines so folks can review them. :-)

Further, while the implementation is new, my understanding is that it's=20
implementing what Apple has done. So we aren't totally rolling our own=20
security system. :-)

Take care,

Bill

--imjhCm/Pyz7Rq5F2
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFEJKIVWz+3JHUci9cRAp3eAJ0U9sdsQkjlR6WO4cX5FpZc4JJiiACdGAYv
PQYB39fjvZNhxE8cwBerww0=
=brHG
-----END PGP SIGNATURE-----

--imjhCm/Pyz7Rq5F2--