In message <442493F7.90100@tadpole.com>"Garrett D'Amore" writes
>jonathan@dsg.stanford.edu wrote:

[...]

>> (Repeated calls for not just a a devfs, but for devfs plus removal of
>> static in-filesystem special-device inodes, and their associated,
>> newfs/mknod-time, *statically auditable* perimsisions (e.g., for use
>> inside chroot() areas or "jails"), is one such case).
>>   
>
>These are all good points.  But they overlook a major consideration.
>
>Most sites (and I've worked with a number of them over the years) that
>care about this kind of thing are not going to jump on whatever
>new-fangled thing we come up with, or even the latest version of the
>operating system, *precisely* because they want the newness to wear off.
>
>These kinds of sites will keep running NetBSD 1.5 until the far-off
>future, and then, only after much debate and testing, consider upgrading
>to 2.0 or 3.0.

Tee, hee. Garrett, you really are new here, aren't you?  There are
several participants on this list who, in point of fact, *do* build
hardened systems based on NetBSD-2.0 or newer.  Personally, I think
Thor and I are a better gauge for the kind of

	``people [sic] who care about this kind of thing'',

(at least in a NetBSD context) than you are.


>It does make sense to consider whether a change like kauth will create a
>barrier to adoption, and what the impact of that barrier is.  In this
>particular, case I see no reason why we should want folks to adopt e.g.
>NetBSD 4.0 if they aren't willing to also adopt kauth.  (I.e. I don't
>think there is some feature or platform support in the proposed 4.0 that
>is *so* compelling that we want *everyone* to adopt to the point that we
>should abandon the idea of including Elad's kauth work.)

Hah. I'd say a NetBSD release that actually worked well on Opteron
systems would be a good start.  I know of several people who want
that, who see absolutely no reason to buy into Elad's work; and who
absolutely *will not* adopt NetBSD-4.0, if it weakens the existing
securelevel semantics in ways which (for example) Thor and I find
objectionable.

If i can put i this way: Elad seems to find it important to offer
finer-grained *EN*ablement of specific actions. Whereas in contrast,
Thor and I find it essential to globally *DIS*able certain actions
(irrespective of which process issues them); and secondarily, to have
a hierarchy of such disablement.

If what you want is a totally-ordered, monotonically-nondecreasing,
hierarchy of *disabling* specific actions, that really doesn't fit
with an independent set of individual bits --- where, by definition,
any one bit in t the collection of bits is *NOT* ordered vis-a-vis the
others.

Just for myself, I could live with a world where individual its could
be cleared from 1 to 0, but can never, ever never reset from 0 back to
1 (except perhaps from the OS console in single-user mode). 
I believe *that* is why Thor proposed "run-levels" with a mask per
run-level (the run-levels being, presumably, monotonically increasing).

But I'm not seeing such machinery anywhere in Elad's proposal.
Am I repeatedly missing it?