eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Google seems to be very interested in the concept of sandboxing. I count three separate efforts the company is involved in. Who knows, they may actually amount to something useful.
The Chrome browser is built around a sandboxed architecture in which browser applications are locked down using Windows-specific features such as Job objects and restricted tokens. I wrote about this at length when Chrome debuted. It’s not especially innovative, but it’s a step in the right direction.
Google bought GreenBorder last year, a company that uses virtualization to sandbox programs and specifically browsers. There hasn’t been any news about this that I’ve seen since the purchase, but the basic point is the same: Prevent anything that goes wrong in the browser from affecting the rest of the system.
The newest and probably most interesting sandbox is the Google Native Client, known casually in the company’s docs as NaCl. (I’m not sure if the “salt” reference has any meaning.) What is NaCl? Many of the quick reactions to it are miles away from what I got out of Google’s white paper on the technology. (The white paper seems like a very honest explanation of the technology to me, even if some of the writing is really bad.)
Some wrote that it’s a new ActiveX-an easy mistake, perhaps, based on a very superficial read of it as a way to run native code inside a browser, but the similarities are only superficial. NaCl is designed with a very different philosophy than ActiveX, which put no real restrictions on what the code in the object can do, and whose only security feature is support for digital signatures. NaCl has a sandbox, and a very restrictive one, more about which I will write below.
Some wrote that NaCl is a harbinger of a Google operating system, and this seems like a real stretch to me. NaCl is a fairly primitive feature; if the operating system is the gorilla, NaCl is probably just the banana. (Of course, Google may be writing other parts of Kong at the same time.) I think it’s much more plausible to view NaCl as a way for the company to make code running on any operating system in any browser safer and more reliable.
NaCl is a run-time environment for native code to run inside a browser, any browser on any operating system that runs on an x86 processor. It will probably appear as a plug-in for Firefox and an ActiveX control for IE. Applications that run in this environment, called modules, are heavily restricted: Many x86 instructions are prohibited, and there is no calling allowed into the host operating system.
Other important features, like hardware exceptions, are disallowed, and this is an interesting symbol of the primitive programming environment. Posix file I/O is provided; I’m not sure if that’s enough for everyone. NaCl does support C++ software exceptions.
NaCl itself provides some system services through NPAPI (the Netscape Plugin API) and a “service run-time” interface that provides memory management, thread support and other such features. There are actually two sandboxes, an “inner-sandbox” which uses static x86 code analysis and x86 segmented memory to block dangerous actions and force safe techniques onto programs.
Yes, you read that right: segments. They’re actually bringing back the whole segment:offset thing and far jumps that we thought went away with 32-bit code. This will likely send many programmers to the windows on high floors, and I’m not entirely clear on why it’s worth adding a fair amount of complexity. (In fact, it’s the use of segmentation that makes support for hardware exceptions impossible.) You can all read the white paper and explain it to me.
NaCl–An Open-Source Project
Or you can read the code. I didn’t mention yet that NaCl is an open-source project. One interesting aspect of this is that it includes a compiler for building NaCl modules and this compiler is a variant of the gcc compiler. I’ll be interested in seeing whether support for other languages follows, although some languages are of dubious value in an environment such as this. You’d only want languages that are meant to create high-performance native code.
Google says in the white paper that it has tested the inner sandbox heavily and believes it to be reliable and robust. The design of it makes this credible to me. I was struck by how, even though NaCl is x86-specific, NaCl modules themselves are very RISC-like. For instance, all data and instructions have to be word-aligned. This is probably for the convenience and performance of NaCl.
There is also an “outer-sandbox” in NaCl. It checks all system calls made from NaCl against a short whitelist of allowed ones and blocks everything else. Currently, only the Linux outer-sandbox is up and running; Mac and Windows are “works in progress.”
Calls into and out of the run-time are performed through structures called springboards (calling into NaCl module code) and trampolines (calling out from modules). These interfaces are dangerous ones from a security standpoint and likely attack targets. Google included them in a list of NaCl components that needed extra scrutiny.
Google reports that, as a general matter, legacy Linux libraries port over with little trouble to NaCl. The company reports on some tests it did porting an H.264 decoder, a physics simulation and Quake. Performance tests on Quake showed it on par with a stand-alone Linux executable.
Google decided to make NaCl x86-specific so that it could optimize the sandbox better, both for security and for performance. Certainly it’s true that almost every desktop and notebook computer runs x86, but not all browsing devices do, and I’m specifically thinking of mobiles. NaCl is also 32-bit only. These restrictions could turn out to be disappointing in the future.
Speaking as a programmer, I think NaCl is cool. Will people find a need for it? Is it a solution in search of a problem? Even though I like the idea of sandboxing, I’m not sure that the trade-offs NaCl makes are the right ones for the market. Perhaps a richer non-native code environment, such as Java or .NET, is a better answer for most of the potential programmers for NaCl. Surely there are programs that need native code performance; do they need to run in a browser, or even in a sandbox?
I applaud Google for all this research work. Whether it ends up as part of Google OS or just educating programmers on the best ways to secure code, the company is asking questions that need to be asked.
Security CenterEditor Larry Seltzer has worked in and written about the computer industry since 1983.
For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer’s blog Cheap Hack.