jonathan@dsg.stanford.edu wrote:
> Indeed, and this touches on an important point often overlooked by
> proposers of change: namely, the *confidence* in a given implementation.
>
> Years-old implementations like securelevel many not be shiny or sexy;
> but because they _are_ years-old, they've had many eyes look over
> them.  Several bugs have been identified and fixed.  Both the
> technique and the implemntation is well-understood in the wider
> security community (e.g., by third-party security labs certifying
> for governmnet use.) 
>
> The upshot is that, for people who rely on existing security-releated
> features to meet those levels of confidence, *NO* new feature is an
> actual substitute for the existing features. By definition, the
> ``new'' feature is not a substitute for the ``old'' feature until the
> new-ness has worn off, the "new"code has become well reviewed,
> well-understood, and widely-trusted.
>
>
> (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.

As long as we don't break something significant in an update (e.g. 3.1),
these kinds of folks should be happy to continue running, regardless of
whatever is included in -current or 4.0.

I don't think this kind of argument taken by itself is a good reason to
make a big change like removing the securelevel stuff.   Or for holding
off *any* change.  Change for change's sake is bad, but I don't think we
should be afraid to innovate, either.

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.)

    -- Garrett

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191