Subject: Re: LONG - Re: /rescue, crunchgen'ed?
To: NetBSD-current <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 08/30/2002 17:57:52
[ On Friday, August 30, 2002 at 13:11:20 (-0700), Bill Studenmund wrote: ]
> Subject: Re: LONG - Re: /rescue, crunchgen'ed?
> You assume all auth modules will be using the network. One of the biggies
> I have in mind is something that would use dedicated hardware. Like
> securecards or some other thing. There you're talking to a local device,
> which will be around. While probably not super-common, these are the kinds
> of things that get added as site-mandates (i.e. if the site decides to use
> it, they tend to require ALL boxes to use it).
I would say any site needing some kind of loadable module to talk to
some kind of external authenticator module, especially just to get a
failed box back up into single user mode, is going to be so extremely
rare that the alternative of not just forcing them to properly
static-link their module is rather "stupid", if not worse. Obviously if
it were me making such policy then I'd require the authenticator code to
be static linked in the first place any. Besides, boxes fitting a
profile like that will have to be in highly secured space anyway, so
anyone attempting to enter that space will already have left an audit
trail a mile long just to get to the keyboard. If technical controls
are not implemented with common sense in mind then they'll just be
bypassed by authorized people until they become more of a threat
themselves than a mitigation.
I think this idea that /sbin/init must support the ability to
dynamically load code is pretty bogus no matter which way you try to
look at it or what assumptions or blue-sky dreams you start out with.
Greg A. Woods
+1 416 218-0098; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>