> Bernstein's proposed solution is to minimize the amount of "trusted code"
> by putting most of the program in some kind of sandbox. Using seccomp or
> running software in a virtual machine are two ways to sandbox code. He
> also wants to minimize the overall amount of code, to make it more
I would like to remind everyone that it is exactly how Google Chrome
behaves (or Chromium the open source version that runs on Linux), using
rendering happens in a very tight sandbox. A vulnerability in a PNG library
will not result in a breach of the system. Firefox does nothing of the
sort, quite sadly.
Chrome is the web browser the OpenBSD project would have designed. It
relies on privilege separation everywhere (and a sandbox on top of that, to
limit the impact of OS-level security flaws, like a buggy syscall). Its
design is similar to OpenSSH.
This is the right model. A PDF viewer should be designed that way, as well
as an email client. In this context, so-called webapps become counter-
intuitively *more* secure than local apps that run with $USER privileges.
And remember than with HTML5 localStorage, so-called webapps don't actually
have to store your data with a remote server. Webapps are not usually
designed that way, but they could. And there is of course NaCl, a Google
browser plugin that can run native applications in a sandbox.
It is certainly quite ironic that Google was apparently attacked through
either an IE flaw or an Acrobat Reader flaw. By design, Google Chrome is
more secure against the first class of attacks, and there has been talk of
adding a sandboxed native PDF renderer to Chrome, but that hasn't been done