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>