Re: Significantly More On-Topic

From: Douglas W. Jones <jones_at_cs_dot_uiowa_dot_edu>
Date: Wed Apr 21 2004 - 11:58:18 CDT

On Apr 17, 2004, at 4:52 PM, Jeff Almeida wrote:

> Bruce Schneier's latest Crypto-Gram newsletter has a blurb where he
> does
> an analysis of the efforts, costs, and subsequent risks associated with
> compromising electronic voting machines to bring forth radically
> different
> outcomes; it's both fascinating and disturbing:
>
> http://www.schneier.com/crypto-gram-0404.html#4
>
> In light of that, and the recent list discussion of the possibility of
> compromising system and python libraries, we should probably consider
> devising a regression suite that, when run, can test with reasonable
> certainty that the python scripts we subsequently run on that
> particular
> machine will produce consistent results.

Generally, there is no way to test for the presence of trojans by any
form of regression testing. This is central to my original objections
to relying on any language that rests on a large interpreter such as
Python for anything other than a prototype.

What we need, wherever possible, is a system architecture with strong
firewalls isolating untestable components from access to critical data.
In a production system, this may involve carefully subsetting the OS
and libraries so that all extraneous code is discarded. This job seems
to have been done already, to some extent by people who've come up with
trusted versions of Linux.

We need, similarly, to build on top of a small language, so that the
compiler and run-time system are reasonably safe. Use of gigantic
libraries is dangerous, unless those usages are carefully controlled
in the consequences they can have.

If possible, I'd recommend using a very strongly typed language. C++
is weak, Java is strong, Ada is strong (and both are about equally
expressive).

In thinking about the impact of language on development costs, it's
important to remember two things:
   -- Modern languages encourage new ways of thinking, and
   -- How you think determines the solutions you use, not the
        language you express your solutions in.
Once you can think in objects, you can program in objects in languages
like C or even assembly language. Object-oriented programming in C
is only ugly, not ineffective:
    object.method(parameter) becomes (object->method)(object,parameter)
It's ugly as sin, sure, but once you understand the broken notation,
it works just fine.

> A pleasant side-effect of having such a test suite would be that it
> also enables us to certify particular os distributions prior to
> actually implementing on them.

Beware of certification as a term. Usually, certification is done
by an outside agency (UL approval is an example of such certification).

                        Doug Jones
                        jones@cs.uiowa.edu
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Fri Apr 30 23:17:14 2004

This archive was generated by hypermail 2.1.8 : Fri Apr 30 2004 - 23:17:29 CDT