Date: Tue, 19 Aug 2003 15:12:58 -0500 (CDT)
From: Mark Tinberg <mtinberg@...urepipe.com>
To: Theo de Raadt <deraadt@....openbsd.org>
Cc: crispin@...unix.com, bugtraq@...urityfocus.com,
	peter@...steddebian.org
Subject: Re: Buffer overflow prevention


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Theo de Raadt wrote:
>>I agree whole heartedly. It is interesting to see OpenBSD transition
>>from a stance of "audit is the only way" to actually employing access
>>control [...]
>
> I persist in my belief that policy-based mechanisms do not improve
> security.  If you cannot make a default policy that everyone can live
> under, you are creating a trap:
>
> 	90-99% of people use the default policy, because they do not
> 	change it

This has to be the golden rule of any functional security system.  99%
of the admins aren't going to change the default system because 99% of
the admins aren't the guys who wrote the system.  In any moderately
complex system the vast majority of the system administrators aren't
going to understand every possible facet enough to be able to
competantly make any large scale changes.

> 	if that policy is restrictive, you have made a decision that
> 	security is more important than useability
>
> 	if that policy is not restrictive, you have made a decision that
> 	useability is more important than security

Um, doesn't this kind of cancel out 8^)

> 	(then there is also the issue of "it is restrictive towards what")
>

And that may be the beginnings of an important distinction.  The
security system needs to be flexible enough to support both the most
anal (can only browse to single intranet site) and permissive (every
desktop runs a quake server).

[snip]
> works?).  I still believe very strongly that efforts directed at
> "security technologies that only experts can use" matter far less than
> "security techologies that invisibly improve everything".

This is kind of the main point I was saying.  A new security system can
only improve overall security when it is widely deployed.  The only way
it will ever be widely deployed is if it's almost completely transparent
to the end of the line admin who runs the system.  Anything that
requires complicated setup is a non-starter, no matter how good and
secure it is.

>
> Hah, there is no public record to live down.  Nor a policy change,
> since we still audit code (with more emphasis on "audit means to
> improve wholesale").  We also modify a lot of software for
> priv-seperation or priv-revocation these days, to internally improve
> specific application's resistance against successful exploitation (for
> the situation of: it has a bug, but if you can exploit it, you gain
> much less).  Since we have more people interested in other areas, we
> can expend efforts in other directions as well.

This is all well and good, and I appreciate the efforts y'all have put
in this area but I think there are more fundamental problems about how
access controls are assigned that isn't being addressed by band-aid work
like privsep.  It would be nice, if possible given the contstraints I
mentioned above, if the system's security archetecture could kill off
the process when it is comprimised, rather than relying on the
comprimise happening in a user-level privilidge section where it
"shouldn't" be able to do _too_ much damage.  It's a good solution that
works with the system we've got, but I think there is a better solution
out there somewhere.

[snip]
> the details of POSIX.  Details matter more than anything else.  Like a
> gun, these things create an process environment which is "POSIX
> maybe".

Anything that requires a bunch of extra work from everybody
(programmers, admins, etc.) is a no-go from the start.  It's unfortunate
that we can't completely start from a clean slate, but it just isn't
practical.

[snip]
> If any security technology shows no success at finding other related but
> minor bugs, I really just don't see the point.

While this seems like a pointless and arbitrary distinction, it is kind
of on the right track.  Programs designed and implemented before
$whizzy_security_system probably exhibit all sorts of ill behaviour that
you'd never notice until the security system starts clamping down on it,
catching bugs.  More of a side effect than a main feature though, ISTM
that whether this happens at all would depend on what kind of security
system you are talking about.  I don't think a security system _has_ to
kick out bugs in existing software to be useful, but if it does kick out
bugs it is evidence that you're on the right track I think.

[snip]
>>>Again, ISTM that the only way to get close to a reasonably secure system
>>>is to only rely on the smallest, most audited codebase possible to enforce
>>>security policy. [...]
>
> whenever I see the word 'security policy' everything after it starts to
> sound a lot like 'blah blah blah maybe NSA or DOD will give me money' and
> my brain fades out...
>
> (sorry, perhaps that is a little bit strong)

Haha, no I wasn't trolling for DoD money I just mean "security policy"
in the generic sense.  These things (machines, programs, people) should
be doing these things (talking to fileserver, sorting text, browsing
web) and not these other things (scanning network, executing shells,
reading accounting's files).  I don't think that requiring each
application to be responsible for its own security is ever going to
work.  It sure hasn't yet 8^)

- -- 
Mark Tinberg
Network Security Engineer
SecurePipe, Inc.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/

iD8DBQE/QoTKFu7F5OUjbGcRAtL6AJ99RkKp4fMz7V8GDvmZRY0Yg2eWzgCfaeVx
OxcYzC40Wh5z+G56zZy48nY=
=DBFH
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists