Archive of UserLand's first discussion group, started October 5, 1998.

Re: No Doubt

Author:Paul Snively
Posted:8/17/2000; 10:21:59 AM
Topic:scriptingNews outline for 8/15/2000
Msg #:19782 (In response to 19767)
Prev/Next:19781 / 19783

Joshua Allen: I'm not masochistic enough to attempt a comprehensive dichotomy in this forum.

Bad news: I am masochistic enough to attempt a comprehensive debate in this forum. :-)

Joshua: The fact that there could be semantic debate over what's "security" and what's not, however, does not mean it's OK to just assume that everything is "security".

This is true, but I feel compelled to point out that you're assuming that we're assuming. This is not the case. There are people who have been dealing with computer security issues exclusively since the 1960's and there is a considerable body of literature and experience regarding it. To briefly summarize, the crucial thing to understand about computer security is that it is, in fact, not a functional aspect of the system. You cannot actually say "this is the part of the system that deals with security" and "this is the part where it doesn't matter." To borrow a phrase from Gödel, Escher, Bach: An Eternal Golden Braid, "security" is an epiphenomenon of the system, or, to borrow a phrase from the complex systems community, "security" is an emergent property of the system. One of the ramifications of this is that analysis of security in a system doesn't lend itself well to reductionism, and as we all know, the western intellectual tradition is all about reductionism.

Joshua: The point is simply that openness has been shown to benefit security in a limited set of domains, and it is not correct to extrapolate this to all domains.

Once again, you're assuming that all that's been done is extrapolation without any supporting analysis; this is incorrect. See EROS for an example of an operating system that attempts to meet stringent "Orange Book" security criteria, has a formal proof of the correctness of its primitive for process creation, and is open source. Also, see The E Programming Language for an example of a new programming language that also has strong security (in the sense of being able to safely implement, e.g. bank-scale financial transactions) foundations. It, too, is open source and has already benefited from the review this has provided, as a glance at the e-mail archives will show.

Even less formally, I can observe that one approach to security is to develop your entire system using tools that support formal semantics, and then prove that the implementation is correct. Jonathan Shapiro did this with EROS' constructor, and Ken Birman's team did this at Cornell with their Ensemble process-group communication system. Since we're not developing all of our software using Objective Caml and proving it correct with NuPrl, we're left with less formal measures. Since the security of a system is an emergent property, the best informal measure of ensuring the emergence of the property is going to be probabilistic in nature, meaning that you'll want to drive the probability that any given piece of code hampers the emergence of the property asymptotically toward zero. The best way to do that is to get as many eyes on the code as you can.

Joshua: Equating inequal things is the hallmark of syncretism and superstition, and when you smell this happening there is usually a witch doctor upwind of you.

Once again, a true statement. The flaw in your reasoning is in the assumption that the security of a system is a functional aspect of that system that can be identified, analyzed, and/or created through reductionism. This is not the case, so your generally-correct argument against "equating inequal things" and "syncretism" is invalid in a security discussion.

There are responses to this message:

This page was archived on 6/13/2001; 4:56:06 PM.

© Copyright 1998-2001 UserLand Software, Inc.