Search Mailing List Archives
[liberationtech] Chromebooks for Risky Situations?
noergelpizza at hotmail.de
Mon Feb 11 08:54:19 PST 2013
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
> 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
More information about the liberationtech