Subject: Re: CVS commit: src/sys
To: None <>
From: Elad Efrat <>
List: tech-security
Date: 06/23/2007 21:24:21
Thor Lancelot Simon wrote:
> On Sat, Jun 23, 2007 at 06:37:20PM +0100, Alistair Crooks wrote:
>> As a software developer, my answer to your question would be "no - if
>> the complete abstraction has been violated, then it will be harder to
>> build models on top of kauth". Has the complete abstraction been violated,
>> or just a part of it? Where is the documentation dealing with the
>> abstractions, the ways it fits into other kernel code, and the direction
>> forward for kauth?
> The documentation is poor, but I think the design principle that's been
> violated here is pretty obvious: don't expose kauth internals or security
> model internals to other code in the kernel, because they will inevitably
> abuse it.  Authentication data should only *ever* be handled via accessors.
> We had that (albeit not in an ideally documented state) and changes like
> the current one break it.  We should find a way to gain the performance
> advantage of the current change without exposing knobs code outside kauth
> has no business turning.
> Thor


while I agree with what you're saying, I am very interested in hearing
what exactly is "poor" about kauth's documentation. this is the first
time I hear about it.

here is the kauth man page:

here is what it says about the interface:

    Kernel Programming Interface
      kauth exports a KPI that allows developers both of NetBSD and
      third-party products to authorize requests, access and modify
      credentials, create and remove scopes and listeners, and perform
      other miscellaneous operations on credentials.

here is what it says about accessor/mutators:

    Credentials Accessors and Mutators
      kauth has a variety of accessor and mutator routines to handle
      kauth_cred_t objects.

      The following routines can be used to access and modify the user-
      and group-ids in a kauth_cred_t:

      [ list... ]

this is the secmodel(9) man page:

it's opened with:

      NetBSD provides a complete abstraction of the underlying security
      model used with the operating system to a set of kauth(9) scopes
      and actions.

shortly after (actually, 2 paragraphs down), there's this:

      The problem with the above is that the interface ("can X do Y?")
      was tightly coupled with the implementation ("is X Z?").  kauth(9)
      allowed us to separate them, dispatching requests with highly
      detailed context using a consistent and clear KPI.

what is so poor about it? what is missing?