Re: Significantly More On-Topic

From: Duke Winsor <duke_at_winsor_dot_com>
Date: Sat Apr 17 2004 - 17:48:19 CDT

[I'm a new arrival. My welcome message from Majordomo
didn't indicate any instructions for this list, so if I'm violating
any of the established protocols, please let me know!]

Actually, Bruce Schneier's estimate of the potential value to the
voter "cheater" is probably very low. I would expect that it will
be based on an estimate of the spoils available historically to the
winner, rather than the advertising spent, which the candidates
might consider "chump change."

Regarding the detection of modifications in the software, Linux
kernels after 2.4.17 have a Distributed Security Module (DSM) which
can do a checksum test of any module to be loaded, to make sure it
hasn't been compromised.

Current research is working to generalize this, to allow not only
secure computing on one host, but extended to distributed hosts,
and the communications in and out of them. See: "Security
Distribution for Linux Clusters," Linux Journal, April 2004, pp. 68-74.

Current work can be found at http://www.linux.ericsson.ca/dsi/ .
Their code (like this project) is hosted at sourceforge.net.

Duke

At 16:52 4/17/2004 -0500, you 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. 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. I'm envisioning
>something that comes in three parts:
>
>(1) a series of short python scripts that test the python core and any
>libraries we're include-ing.
>
>(2) a couple of shell scripts to resolve dynamic symbols in the python
>core and said python libs, and produce a list of dynamic link libraries
>and specific functions therein to analyze.
>
>(3) a series of small c programs that test the various functions
>contained in the dynamic link libraries we're linked against.
>
>One possible end-result of such an effort would be an SCM tool that could
>obviate the hardware discussion as well: if done properly, we could
>effectively say, "Run it on anything you like, as long as it passes the
>standalone SCM test suite." Then, it becomes a "Palms in Maine, Ice Cubes
>in Hawaii, it's all good" scenario the hardware-specific-solution vendors
>will find even more difficult to compete against.
>
>jeff :)
>
>--
>
>************************************************************
>Jeff D. "Spud (Zeppelin)" Almeida
>Corinth, TX
>spud@spudzeppelin.com
==================================================================
= 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:10 2004

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