[liberationtech] Chromebooks for Risky Situations?

[Rich Kulawiec]

On Mon, Feb 11, 2013 at 12:54:27AM +0700, Uncle Zzzen wrote:
> Obviously systems are too complex for most people to really figure out
> what's exactly running on their computer, and modern systems (from smart
> phones to unity) make it harder and harder for users (even "power users")
> to peek under the hood.

Agreed.  Further, complexity == insecurity.

The way that you build secure systems isn't by adding code: it's by taking
as much away as you possibly can, by stripping them down to the absolute
minimum required to accomplish the required computing tasks.

Why?  Because we don't know how to write secure code.  Therefore, to a
first approximation, the less code is in play, the better chance we have.

(That's an unhappy statement, but I really do think the last 10, 20, 30
years bear it out.  Even when we think we've written secure code...we
probably haven't.  Timely example:

	Lucky Thirteen: Breaking the TLS and DTLS Record Protocols
	http://www.isg.rhul.ac.uk/tls/

In that case, the code is insecure because the spec is insecure.  Oops.)

So if I were trying to design a secure operating system and application
environment for liberationtech, I would do several things that are,
depending on how you look at them, either a radical departure or a
return to a time when simplicity was recognized as a virtue.

1. Abandon the idea that a full-blown general-purpose operating system
is required.  It's not.  Start with something that's fairly lean and which
has a focus on security (e.g., OpenBSD) and start figuring out what can be
stripped out of it (based on target devices and application environment).
This includes not just the kernel, but *everything*: if there isn't
a need for the C compiler in the target environment, then it shouldn't
be there.  Neither should /usr/include.  Or the applicable man pages.
Ruthlessly strip out every file, every line of code that isn't needed.

2. Abandon all-singing all-dancing applications.  They're enormous.
They use massive code bases which in turn use massive libraries.  And to
borrow from the quoted passage above, they make it harder to peek under
the hood.  So: no GUI.  Don't tell me it can't be done -- I've done
it.  Anyone who can use Thunderbird can use mutt, for example.  And given
the enormous reduction in attack surface as well as required system
resources, this effort should go as far as possible.

3. Abandon the idea of application installation, updates, etc.  These
mechanisms present an attack surface.  So don't have them, period.
Make the entire distribution, OS and applications, one monolithic
self-contained entity.  No app downloads.  No updates.  No choices.
(Of course this is additional motivation to make it as small as possible.)
You want a new version?  Then you get a new version, in its entirety.

4. Onboard bidirectional default-deny firewall.  Make the user explicitly
authorize any/all traffic in either direction.  Scream like hell when
something is trying to get in, and just as loudly when something is
trying to get out.

5. Design to run off read-only media.  Thus (as an adjunct to 3) the
way that you "upgrade" is to replace that media.  Design to use
external media for storage so that nothing is ever present on the
system itself.

What I have in mind is something small enough to fit the entire
distribution on a 64M USB stick/memory card or smaller.

Yes, this approach presents some problems of its own.  I know.  I could
spend the next hundred lines enumerating just the obvious ones.  But it
also solves (or at least makes credible attempts at solving) a different
set of problems that I think are more important.  And I think it has a
fighting chance of reducing the code base and thus the attack surfaces
to a tractable size.  Maybe.  Possibly.  On a good day.

---rsk