Karsten M. Self kmself@ix.netcom.com
Wed Jan 29 22:07:47 PST 2003

on Thu, Jan 30, 2003 at 12:41:40AM -0500, John S J Anderson (jacobs@genehack.org) wrote:
> Around Thu, Jan 30, 2003 at 05:09:45AM +0000, Karsten M. Self gave forth with:
> > Graham largely supports my conclusion:  patching isn't effective
> > against this kind of threat.
>    For values of "this kind of threat" that equal "a flaw that can be
>    exploited via a single well-crafted UDP packet, and that relies on
>    yet another instance of the world's best known dumbass C coding
>    mistake".

...which doesn't exactly speak for the mistake's scarcity of occurance.

I *was* going to add a comment to the effect that there are
vulnerabilities for which an appropriate patching mechanism and protocol
*are* effective.

The two approaches might be seen as the different philosophies Debian
and OpenBSD bring to security.  I'll vainly head of the flames at the
start by saying:  yes, each system uses multiple security practices.
However I am focusing on core features of each.

Debian relies principally on a trivial-to-use update system which
strongly promotes keeping systems current within a matter of a day or so
of the latest security updates.  It's quite possible, and quite common,
for administrators to schedule a nightly package sync with
security.debian.org, and download the latest updates for a manual review
and update in the morning.  One command brings the entire system up to

OpenBSD relies on preemptively screening for security bugs.  Major
system libs are rewritten to avoid the standard class of dumb mistakes.
Code audits, and careful selection of packages in the core system are
also undertaken.  It's not unheard of to fork a project for a security
rewrite (BIND) or reimplement functionality from scratch.  All efforts
are focused on creating a system that's secure by default.

Debian might be seen as the "get the patches out soon and everywhere",
while OpenBSD is "harden the hell out of the system from the get-go".

Truth is:  Debian also performs (or benefits from) code review.
OpenBSD's ports system can be used to keep systems updated.

Moreover, the reality is that security is a process, and tackling the
problem from multiple perspectives reduces total system exposure.  Use
secure tools.  Write secure code.  Check it.  Twice, and independently.
Provide updates, in a timely and readily accessed method.  Don't run
unnecessary services.  Filter your public interfaces.  Log traffic.
Review your logs.  Rinse.  Wash.  Repeat.

I'm dumping various thoughts and notes on this incident TWikIWeThey:



Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
   At the sound of the toner, boycott Lexmark:  trade restraint via DMCA.

More information about the linux-elitists mailing list