Subject: Re: Integrating securelevel and kauth(9)
To: Garrett D'Amore <email@example.com>
From: None <firstname.lastname@example.org>
Date: 03/24/2006 19:09:24
In message <442493F7.email@example.com>"Garrett D'Amore" writes
>> (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
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
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?