[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/37962: libkvm is busted due to kauth_cred redefinition
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,
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
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
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
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)
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
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. :)
Main Index |
Thread Index |