Jonathan Stone 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? 

The code is on NetBSD's CVS, publicly available, you can download it
(the kauth(9) subsystem is just one file, kern/kern_auth.c) and have
a look.

There is really no other answer to your question. Obviously, code that
has existed for years will gain more confidence than new code that
exists for less than a month.

Perhaps this is why the code is located on a separate branch, so it
can be brushed out and reviewed by people who are specifically
interested in doing so? with an attitude like "why should I trust
this new code", how do you expect to move towards a modern system?
or are you not even interested in doing that?

> Or to concerns, as per Thor's over whether
> it's an effective replacment for securelevels?

As I've stated, and I assume several others who commented on this thread
already, you will be able to maintain the *exact* same behavior you have
today with the new code.

As a matter of fact, this was a key part of my suggestion, that you
might've overlooked.


> 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
> 
> 	"can this particular  user (or process) can do some particular operation"
> 
> 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.

Of course it is -- you just took what I wrote and twisted it a bit so
it doesn't match the reality. :)

What you have inside quotation marks is something I have never said.
What I did say is that the code will, instead of checking the
securelevel variable itself, call a function with the (a) request made
and (b) request context.

This function, that is internal (and so does not limit us to any ABI
anymore), can do whatever we want.

I can make this function check for a bit set in a certain bitmap.
Someone else can make this function dispatch the request to a userspace
daemon, which will forward it to a centralized security server in a
FLASK-like model. You can make this function simply check for the value
of securelevel and can allow/deny the request according to it.

So instead of directly accessing securelevel in your code, you'd
have a function do it for you, regardless of any uid or whatever.

How will this change any behavior?

> 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 misunderstood my suggested change, then, because the purpose of it
wasn't to give any users special privileges, or introduce any new
behavior, but rather make it easy to change the behavior if so desired.

Right now, if you have code checking for securelevel against a certain
number, you can't instantly tell why it does so and what it attempts to
prevent without digging further into the code. *That* is nebulous.

If you have a function call that looks like:

	kauth_authorize_system(p->p_cred, KAUTH_SYSTEM_DRIVER_IOCTL,
	    NULL)

You have to agree it's clearer what the code is trying to do. You
can also open up the kauth(9) man-page and see what the
KAUTH_SYSTEM_DRIVER_IOCTL operation in the system scope means.

Furhtermore, the kauth_authorize_system() function can do whatever
you want! I really don't know how more I can say this, but the beauty
of kauth(9) is in that it allows you to plug-in whatever functionality
you look for.

As far as you care, you can just have it go like "if the requested
operation is X, and the securelevel is Y, deny the request", and be
done with it. No process/credential context involved whatsoever.

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

Oh, I will do so by all means.

> And please don't offer these nebulous "kauthd" callbacks as a
> substitute, not until they've been well-audited and well-reviewed.

What are you talking about? what is "kauthd"? and, I would *love* a
security audit of my code from you.

-e.

-- 
Elad Efrat