jonathan@dsg.stanford.edu wrote:
> 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.
>   

I was exaggerating a little bit when I said 1.5.  But the point is they
are likely to trail at least a major release or so, I think.

Your experience in the arena with NetBSD is no doubt more extensive than
mine.  Although,  based on the kind of stuff I've seen in dealing with
e.g. Sun customers and DoD/govt users, the folks who care most about
things like proveable security are the same folks who won't adopt a new
release of almost *anything*, just as a matter of principle.

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

So, please forgive my ignorance here.  Is 3.0 (or some possible 3.1)
unlikely to meet the need for a something that runs well on Opterons? 
(I know there has been some recent work on the nForce support, but I
don't run netbsd on x86, so I've not followed too closely.)

If Opteron platform support is such a compelling feature/need, the
perhaps we should seriously consider spinning a release *now* without
putting any of the other stuff we've been talking about into it.   (Or
maybe we need some pullups into a 3.1 release.)  Of course, core@
decides those kind of directions.

In this case, maybe it is better to defer kauth (or whatever it becomes)
til after 4.0 branches.

But I also think, you have to allow for forward progress at *some*
point.  Deferring forever, just because its a new-fangled gizmo, is the
wrong approach, I believe.   I'm talking in the general case here, not
kauth specifically.

Whether kauth is ready for inclusion in -current or not is a different
question (and should be based upon its own merits, which I am not going
to speak to here, as I'm not an expert), but I don't think it is right 
to deny the idea just because it is "new".  I got the impression from
your original mail, that this was justification enough.

I since see you have more specific considerations and I think Elad or
someone else advocating kauth should try to answer those.  I look
forward to seeing what response he will have for you.

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