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 -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
