Securing Google's Chrome OS

Andrew Jaquith

Today, I received an e-mail from eWeek's Brian Prince asking about how Google might make good on its promise to make their upcoming Chrome OS more secure than the operating systems we know and love. Here's my long reply to him, lightly edited.

Google is starting from a clean sheet of paper, so they have a lot of freedom to design the OS the way they want. From a security perspective, Google has a lot of options, ranging from evolutionary to radical.
 
On the more evolutionary side of things, Google could have chosen to make an OS that looks and acts a lot like today's operating systems, with a windowing system, local file storage, multi-threaded processes, a Web browser, and locally installed applications written in native code. Windows, GNU/Linux, and OS X are all like that. The difference is that Google would seek to do some or all of these aspects more securely. For example, they could implement something like SELinux, a package that adds mandatory access control to Linux. This would allow the OS to sandbox malicious processes so they don't infect the rest of the system. The browser, too, could be done better. Safe bets of what Chrome OS will include are a browser with multi-process tab support (like the Chrome browser), which isolates each browser window process, and is therefore more secure than other browsers.
 
At the extreme end of what Google might do is the iPhone model, circa version 1.0 of the OS. That is, the OS is a totally sealed box with no third-party app support. All "apps" are Web apps, with a trusted bootloader that verifies software integrity of core OS files at time of bootup. The first iPhone OS was really like a toaster: there wasn't anything to mess with, so the users couldn't get themselves in trouble. Apple later added native app support in iPhone OS 2.0, which required new apps to be digitally signed. This is something Google could do also if third-party native apps were supported.
 
My personal hunch is that Chrome OS will be closer to a toaster. The applications it will run will be primarily, if not exclusively, Web applications like GMail, Google Docs, and Picasa. That means the primary application they will need to secure will be the Chrome browser, which they have demonstrated an ability to do already. For those cases where the browser needs to run a native code plugin, they will use the Google Native Client APIs. The research I've read on NaCl is quite encouraging; it runs native code, but the code is "verified" beforehand so that it can't do naughty things, or at least is less likely to. For an overview of the goals and security posture of NaCl, see this excellent, prescient Matasano post: http://www.matasano.com/log/1674/the-security-implications-of-google-native-client/
 
Next, if we make the assumption that Google wants things to live in the cloud, we can probably assume that there won't be a user-accessible file system. That, plus the desire to lock down the operating system, suggests that all file storage will be in the cloud. For the core OS, I consider it likely that the OS itself will have a trusted bootloader that verifies the integrity of the OS at bootup. The trusted bootloader, combined with a MokaFive-style auto-wiper, could ensure that the OS is always "clean" at bootup, and that the user files stay separate from the operating system. For those of you with long memories, the idea of a trusted OS isn't new. Indeed, Microsoft Research implemented process isolation and trusted bootloading in its experimental Singularity OS in 2005. What's new is that Google will actually try to commercialize it.

In summary, if I were king, I'd make the "OS" as we know it a lot thinner and compact, without support for 3rd party applications, and cloud-based storage. Combine that with process isolation, mandatory access control, trusted bootloader and a primarily browser-based user interaction model, and you'd see an OS that is indeed a lot more secure.

Comments

re: Securing Google's Chrome OS

Re: arj: Roger Grimes likes straw men: http://bit.ly/aVnyK. See any claims of "perfect security" here? http://bit.ly/rjHTg. Very sloppy, Mr Grimes.http://googleblog.blogspot.com/2009/07/introducing-google-chrome-os.html"And as we did for the Google Chrome browser, we are going back to the basics and completely redesigning the underlying security architecture of the OS so that users don't have to deal with viruses, malware and security updates."How is that quote not stating "perfect security"?You would have to be PERFECTLY secure in order to accomplish any of those three goals, much less all three.Please, Andy, tell me how I misinterrupted that statement?Please reply to roger_grimes@infoworld.com

re: Securing Google's Chrome OS

Roger,In your article, the rhetorical device you used was a classic "straw man": creating an easy-to-discredit opponent by claiming they said something they did not say: that they would create a "perfectly secure" operating system.I don't see how you could conclude they said that, considering that you did not link to a single primary source or directly quote anyone at Google -- until your message post this morning on this blog. If you think that "don't have to deal with viruses, malware, and security updates" must mean "perfect security", and can ONLY mean a zero-defect, risk-free, bulletproof OS, then we have entirely different conceptions of the English language.When I your article was "sloppy" in my tweet, that is what I meant. Considering that you work for Microsoft, I expected better from you.There is no question that Google is setting a high bar for themselves. But that bar is not perfection, and no common-sense reading of one sentence from a blog post would suggest that perfect code is what they aspire to. I interpreted what Google is aiming for is "a lot less hassle factor" related to keeping the PC clean from viruses and updates. They can achieve that goal without creating an OS that is "PERFECTLY secure" (your term, not theirs).

re: Securing Google's Chrome OS

Don't pin your hopes on a 'cloud based' file system, this just won't work in bandwidth challenged places, like most outside California...

re: Securing Google's Chrome OS

I think the statment in the infoworld article, "the best indicator of future behavior is past behavior." is incorrect. The best predictor of the future is the present. Decisions and actions are made in the present not the past and hence once can only make predictions about the future from what is happening right now.