Re: Vnode scope implementation

[Elad Efrat <elad%NetBSD.org@localhost>]

David Young wrote:
> On Tue, Jul 21, 2009 at 12:25:37AM +0300, Elad Efrat wrote:
> > David Young wrote:
> > > On Thu, Jul 16, 2009 at 07:39:15PM +0300, Elad Efrat wrote:
> > > > David Young wrote:
> > > >
> > > > > Isn't it hard to know that the design of kauth(9) and the placement of
> > > > > the hooks is correct for anybody's purposes---Apple's, NetBSD's, yours,
> > > > > mine---when you do not use the API for anything?
> > > > How is the API not in use? what do you think implements "root" and
> > > > "securelevel" for several years now? :)
> > > Sorry if it wasn't clear from the context, but I was asking about the
> > > vnode scope.
> > In that case your question makes very little sense, given the subject
> > of this thread is the vnode scope back-end. In other words, no hooks are
> > added, so you can't tell if their placement is correct or not.
>
> The question stands, how do you know that the design of anything in
> kauth(9) is correct until you use it for something?

No, it does not stand. You first asked about kauth(9), and then said
you are asking about the vnode scope. Now that I've told you that the
vnode scope itself introduces no new hooks, you are once again asking
about kauth(9). That is called wasting time.

The implementation of kauth(9) is very, very simple. It does not add
"hooks" as you're trying to imply, but rather replaced what used to look
like this:

        suser(...);

to use the kauth(9) interface.

If you are unsure whether it's "correct", I will once again repeat what
I've said two emails ago: it is already in use. When we did the
implementation on the branch, mjf@ took care of regression tests. We
already discussed having them in tree. We will not go over any of the
above subjects again.

> > > But that is just maintaining the status quo.  Is that such a big
> > > pay-off?
> > I think your assertion is wrong, but I also think we have different
> > definitions of what a big pay-off would be. Could you please state
> > what a big pay-off would be, from your point of view?
>
> It would be a big improvement if a user could run any process with the
> least privileges that he thought the process needed to do its job, and
> if he could read from the kernel a reliable list of the privileges that
> any process was running with.

You do not understand what kauth(9) is or how it should be used, then.

Kauth(9) is a kernel interface. A user does not interact with it
directly. It does not provide capabilities, privileges, or any way to
query for them. It's an infrastructure that allows you to implement the
kernel part of such features, but does not dictate the userland<->kernel
interface.

For example, kauth(9) provides you with "credential private data" so you
can attach secmodel-private data to credentials in the system. It also
provides you with the "credentials scope", so you can hook into the
credential's life cycle and manage the aforementioned private data.

The above was mentioned enough in documentation, papers, code
comments, email discussions, several interviews, release notes, core
minutes, etc. that we will not go over any of it again as well.

> > > A paper and an abstract do not a compelling security demonstration make!
> > Same question as above -- could you elaborate on what a compelling
> > security demonstration would be, from your point of view?
>
> To start with, it would be runnable code!

That is beyond the scope of kauth(9). It's a goal as mentioned by my
paper from 2006. NetBSD developers have taken a shot at it (agc@, bad@),
as well as users, see

        http://mail-index.netbsd.org/tech-kern/2008/03/17/msg000599.html

(along with some stuff that was discussed off-list.)

Whether they publish the code or not is not my concern. If you want to
see code, you should email the person who wrote it.

The work I'm interested in doing is laying down the foundations:
finishing the transition to proper use of kauth(9), and the secmodel
abstraction. I don't see anything wrong with me continuing with that
work, and others starting in parallel work on alternative secmodels.

-e.