Re: kern/37962: libkvm is busted due to kauth_cred redefinition

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

The following reply was made to PR kern/37962; it has been noted by GNATS.

From: Elad Efrat <elad%NetBSD.org@localhost>
To: YAMAMOTO Takashi <yamt%mwd.biglobe.ne.jp@localhost>
Cc: simonb%NetBSD.org@localhost, gnats-bugs%NetBSD.org@localhost, 
thorpej%netbsd.org@localhost,
        Andrew Doran <ad%netbsd.org@localhost>
Subject: Re: kern/37962: libkvm is busted due to kauth_cred redefinition
Date: Thu, 07 Feb 2008 12:35:01 +0200

 Hi,
 
 For history's sake, I'll note why things are as they are today.
 
 Kauth(9) is part of a larger roadmap to introduce several modern
 security features to NetBSD. Some of these have made their way to the
 tree, others haven't (yet). Kauth(9) specifically will allow easily
 choosing the security model in which NetBSD operates.
 
 The work was done gradually. First, the interface was introduced and
 tested, followed by a tree sweep to make existing code use it, although
 the functionality remained as we used only KAUTH_GENERIC_ISSUSER
 actions. We then removed the old routines kauth(9) replaced. Since then,
 work is underway to properly classify the kauth(9) calls -- abstracting
 the security model -- so that the secmodel back-end properly interprets
 them and applies the security policy it's meant to implement. I'll note
 that this classification is required to take place regardless of the
 security infrastructure.
 
 That's where embedding the structure in kern_auth.c comes into the picture.
 
 The current work procedure of security model abstraction is "grep
 KAUTH_GENERIC_ISSUSER". It is safe to presume that there is no misuse of
 credentials in the tree: everything is done via kauth(9) authorization
 wrappers. While nothing other than policy guarantees new code won't
 be using eg. kauth_cred_geteuid() for access control, having the
 structure embedded in kern_auth.c guarantees that the at leas the KPI
 will *have* to be used -- and, in light of this, it is assumed
 developers will prefer calling the authorization wrappers.
 
 Back to the suggestion of sharing a structure definition, I think that
 at some point we will *have* to do it; not only for kauth(9), but part
 of a larger policy (proper exposure of kernel internals, etc.) -- though
 I think the relevant context necessary for deciding what to do here is
 missing.
 
  From my own, short experience, I can tell you this much:
 
    1. Lots of code abuses APIs and coding policies: Many work was done to
       normalize the way access control is performed in the kernel.
 
    2. I don't rule out people justifying the above in the sake of micro
       optimizations: In fact, shortly after the brief introduction of the
       shared structure definition I've seen suggestions to sweep the tree
       *back* to use direct structure members rather than the kauth(9)
       KPI.
 
    3. New code is likely to be introduced to the tree using
       KAUTH_GENERIC_ISSUSER even though it's been actively removed from
       the tree. I know because I've dealt with such.
 
 Given NetBSD is a volunteer project, I believe the decision on what to
 do here isn't based on the question of "is it better to have a duplicate
 structure definition in the code?" -- for which the answer is clearly no
 -- but rather "what would be the cost of sharing a structure
 definition?" -- and, unfortunately, the answer for this one is "a lot of
 headache and overhead in the current security model abstraction
 process".
 
 It is very easy to make such nearly-arbitrary decisions when they have
 close to no impact on you. The said overhead, if there will be any,
 falls on those who are performing the security model abstraction,
 changing the process from a simple "grep" to tedious constant checking
 that no code pulls in the structure definition, bypassing the KPI.
 
 Given the current reality, I think the bottom line is that it will be a
 lot cheaper to simply maintain, for the moment, a duplicate structure. I
 tend to believe it's a lot easier to sync it than to do sweeps on the
 tree looking for all the possible ways one can abuse credentials once
 their members are exposed. Again, I know because I did this.
 
 If, however, you do decide on sharing a structure definition, it would
 be irresponsible not to accompany it with a strict and clear policy of
 when it should be used -- which is exactly two cases as of this writing:
 kern_auth.c and kvm_proc.c. My only concern is that this policy will not
 be followed or enforced... but only time will tell. I hope I'm wrong. :)
 
 -e.