From kragen@dnaco.net Fri Aug 14 11:16:20 1998
Date: Fri, 14 Aug 1998 11:16:19 -0400 (EDT)
From: Kragen <kragen@dnaco.net>
To: David Holland <dholland@hcs.harvard.edu>
cc: Kragen <kragen@pobox.com>, astor@guardian.no, bob@earthrise.demon.co.uk, 
    security-audit@ferret.lmh.ox.ac.uk, netbug@ftp.uk.linux.org
Subject: Re: quick fingerd audit, and patch (fwd)
In-Reply-To: <199808141500.LAA26132@hcs.harvard.edu>
Message-ID: <Pine.SUN.3.96.980814110458.21889a-100000@picard.dnaco.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Keywords:
X-UID: 1254
Status: O
X-Status: 

On Fri, 14 Aug 1998, David Holland wrote:
>  > And extreme insecurity.  Fifty different people doing the same security
>  > check in fifty different places guarantees someone will get it wrong
>  > somewhere.
> 
> In these situations, it is better for all parties to make any
> necessary checks. Basic principle of defensive coding.

Well, there are two different situations -- parallel and serial redundancy.

Serial redundancy increases security, if testing is done properly --
although it creates the temptation to skimp on security.  Serial
redundancy looks like this:

	untrusted --> check 1 --> check 2 --> trusted

If either check 1 *or* check 2 fails, access is denied.

This creates the temptation to skimp on testing, because simply testing
the system under real-world conditions is not enough.  check 1 and
check 2 need to be tested separately, and both of them need to work.
What often happens in the real world is that one of them has an obvious
fail-open bug, but never gets tested in isolation from the other
(working) check.

This decreases security.

However, the situation we're talking about here -- applications
checking their syslog output for vt bombs -- is the other kind of
"redundancy", parallel redundancy.

Parallel redundancy isn't redundancy at all, for security purposes.  It
looks like this:

untrusted --> check 1 --> trusted
untrusted --> check 2 --> trusted

If either check 1 *or* check 2 succeeds, access is *granted*.  This
means that you have less security than if only one of them had been
present.

If the number of parallel paths is significant (for example, there are
about 50 daemons that use syslog) the probability of at least one of
them being buggy is overwhelming.

Parallel redundancy is simply bad engineering for security.

Kragen


