StrongBox Q&A

From: Liam Helmer <lists_at_strongboxlinux_dot_com>
Date: Fri Apr 23 2004 - 13:00:11 CDT

Hi all! I'm new here. I wrote in because I'm working on a project that
seemed to be complementary to what's going on here.

I've had a couple of questions asked already, so I thought I'd answer
them to everyone. It sounded like this should be continued on the demo
list... so I'm going to do that.

>On Thursday 22 April 2004 10:35 pm, David Mertz wrote:
> >> There are a number of requirements we will have for an "EVMix"
> >> live-CD--most of them what we DON'T want included more than what
> we
> >> want. For example, if we leave out all networking code, that
> makes us
> >> feel even more confident remote attacks won't accidentally be
> enabled.

My current target for StrongBox is webhosting so, obviously, there's
lots of networking utilities. However, I'm not averse to creating a
version with networking stripped out of it; that just means that it'll
be smaller. ;-)

On Fri, 2004-04-23 at 02:52, Fred McLain wrote:
> Hi Liam,
> This sounds interesting. I have a few questions:
> What versions of Python and QT are you supporting, our current demo has
> restrictions in this area.
> We also need to install packages at a system level, can this be done
> with Strongbox?

The simple answer is this: if we can get it to run on ANY linux
distribution, we should be able to get it running fine on StrongBox.

For a more thorough answer, I should back up slightly. I refered to it
as a project, not a distribution. I'd call it a "meta-distribution"
(which I know is used synonymously with distribution sometimes), of I'd
consider projects like Knoppix a member. What I'm doing is taking little
pieces from everything else (yah open source!) and creating something
new out of it.

The main StrongBox "OS" runs out of RAM, taking up as little as 60MB. My
minimum requirements for running strongbox are 128MB RAM, or else a swap
partition on the hard disk and 64MB RAM. The OS is responsible for core
functions: bootup and shutdown, managing disks, and memory, saving
configurations, performing upgrades, and starting/stopping bundles. This
piece, including everything (kernel, modules, OS, etc) fits on a
business card size CD.

The "bundles" are, essentially, complete distributions (of any linux
flavour) that run in a secure context under strongbox (a la
linux-vserver project, www.linux-vserver.org). I generally put them in a
read-only format, and then provide tools for storing runtime changes of
particular directories, like /etc (or whatever) to disk.

The architecture of StrongBox is such that I can run a complete
distribution (Fedora, Gentoo, Debian, etc..) in a separate context from
the main StrongBox OS. StrongBox deals with the hardware, and then
allows the software to run in a more secure layer. Currently, the stable
linux-vserver (what I'm now using) supports per context process
invisibility, changing the linux capability set of processes, and a
somewhat more secure chroot. The development vsersions (which I'm moving
towards using) support an actually separate namespace, and have more
fine-grained security on contexts, which is even better.

These provide some security features, the rest is provided through
ubiquitous use of x509 certificates to sign OS pieces (OS,
configurations, bundles, kernel modules, etc). These signatures are then
checked prior to loading any component. This way, if someone
unauthorized saves a configuration, the configuration won't boot, and a
search will be done for an authorized version to boot from.

You could run a distribution just as a hard disk install (or on an LVM
partition, etc), under StrongBox. You could also create a cloop (like
knoppix does) for it. It sounds like the best solution here might be for
me to build you customized version of the StrongBox OS, with all the
network features ripped out. Then, we can have an install of whatever
flavour of linux works best on a development box. This is used to create
a cloop, which is verified, signed, and put onto a CD, and can run under
the OS.

Note: here's an interesting architecture idea for you:
X windows requires a lot of privileges on an OS. However, a GTK
application for voting probably doesn't require so many. One thing that
you could do is have the X server running in it's own context, and the
voting application that connects to the X server connecting to it from a
context with much less privileges. That might require at least some
local networking however: i.e. localhost.

> We may be using a multi-session CDR for boot so that the voting station
> can write back the election results, it sounds like this might be
> compatible with what you are doing. True?

I have no idea what the implications are for having a CD-Rom mounted
(for running gtk, etc) while you're burning a new session to it! At
first glance, I would imagine that it'd be unreliable. Here, I did a
search, and here's what I found:

http://mlug.missouri.edu/~rjudd/projects/cdburning.html#Warnings

However, a myriad of options would be available for saving votes. I'd
suggest having each voted signed using a certificate (or multiple
certificates, such as one per voting station, and one per voter)
encrypted to a central election key (or several, for better
recoverability), and then stored to a read-write medium, such as a USB
key or a cheap flash device (like a compact flash drive with an ide
interface). An internally installed compact flash (or two, with both
being written to for better reliability) would seem to make the most
sense: it's cheap, reliable, solid state, reuseable, and is hard to walk
off with.

However, there's no reason you can't have an OS CD and a votes CD too.
I'm just not sure that writing to the CD after each vote (which you'd
need to do for reliability) is the best way of going about it.

On Fri, 2004-04-23 at 14:29, Douglas W. Jones wrote:
> In the long run, I happen to believe that Linux, as a warmed over
> Unix, can never meet the strongest security demands. The problem
> is, the core ideas of Unix represent the mature thinking on many
> issues of the early 1970's, and we need to move beyond the 1970's
> in our thinking on these issues.

Well, I'm hoping that we're moving a little beyond the 70s. Certainly,
public-private key cryptography wasn't big then, and nor were
virtualized OS layers ;-) Linux is really a much more modern unix than
many of the others out there, and is getting more modern every day,
IMHO.

Personally, I think that the one good way of having better security is
simply using a lot of read-only components, making the OS much less
volatile than it is in modern PCs. The biggest security problem in
modern PCs, AFAICT, is having such a volatile OS!

> because it was common knowledge that personal computers made
> research on secure systems irrelevant.

<grin> So true. It's amazing how things like that keep coming back, huh?

> That's the attitude that gave birth to Windows, MacOS and a flood
> of bad security ideas at the applications level, and as a result,
> the marketplace today looks up to Unix as a model system.
> There are some other competing secure Linux ventures, and evaluating
> them is no small task.

Absolutely, there's about a billion ways to skin this. But, hey, I'm
interested in helping out, and hopefully we can create something
useable.

Cheers,
Liam
==================================================================
= 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:18 2004

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