Subject: Re: login.conf for selecting password verification method (was Re: Kerberos is on by default?)
To: None <tech-userlevel@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-userlevel
Date: 07/11/2000 13:57:00
[ On , July 11, 2000 at 13:36:46 (+0400), Oleg Polyanski wrote: ]
> Subject: Re: login.conf for selecting password verification method (was Re: Kerberos is on by default?)
>
>         When  software  has `buffer overflow'  problem (either  stack or heap
>         overflow) static linking will not help you, it's just another kind of
>         security through obscurity.

No, it's not "security through obscurity".  Quite the opposite in fact!  ;-)

The primary security reason for static linking (or using kernel-level
shared libraries) is to avoid all of the *many* tricks that can be
played with full dynamic linking.  Just as you'd never want to allow
runtime loadable kernel modules of any kind in a secure system, neither
should you allow dynamic linking.  The risks outweigh the advantages in
some environments.  I won't discuss what these risks are claimed to be
because that's a subject that'll fill whole books -- suffice it to say
that there are some people (such as myself) who will always err on the
side of caution in this arena and it will take a complete mathematical
proof of the safety of dynamic linking to convince us otherwise.

The secondary reason for static linking (and even more so for kernel-
level shared libraries) is performance.  There's a definite and very
noticably painful bite taken out of your system by dynamic linking.  Yes
a P-III 770MHz CPU can mask this pain unless you're a real CPU hog who
also goes nuts creating processes.  However not every useful system out
there is anywhere near that fast.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>