[liberationtech] Chromebooks for Risky Situations?

[Andreas Bader]

On 02/11/2013 04:15 PM, Rich Kulawiec wrote:
> 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.
Don't you think that e.g. DSL (Damn Small Linux) has less code than Android?
I mean you can't simplify that by saying "This System is the most
secure" if you mean "this system is the smallest.".
I think you have to achieve a good compromise between security and
simplicity.

Andreas