Header Image

Programs learn to play in their own sandbox

Among all of the New Year's normal ebb and flow, predictions for the upcoming year are ubiquitous. More than a couple of these predictions proclaim that 2010 will be "The Year of the Sandbox". While I think this is a sensationalist way of putting it and that it would be hard to pin down any timeframe for such a technology to become the norm, I do agree that the sandboxing of processes is becoming popular.

In fact, if you look at the technology as a whole, virtualization can be thought of as macro-sandboxing - that is, making sure that one set of processes (the guest) cannot interact with another set (another guest). Virtualization has taken off and now sandboxing is headed towards stopping individual processes from communicating with things it shouldn't.

The Theory
Sandboxing is not a new idea and is a simple idea. Basically, if you limit the access that a running computer process has, then it limits both good and bad things. If you design a program to work properly under normal circumstances while limiting the access it needs to other data, then you have created a sandbox. Then, if this program is used in a manner which was not intended, the effects are also limited. On top of this, the portions of the program that are intended to interact with other resources (such as the operating system or other processes) are hardened with the most strict security practices possible.

The end result is a recipe for success.

Harbingers of technology
Google's Chrome browser is already sandboxing itself. According to Google's Chromium Blog all of the Javascript and HTML processing is sandboxed in what is known as the renderer class. Each plug-in is separate from the renderer. As a result, Chrome runs in several OS processes, one for each tab and plug in. On top of this, the renderer is hardened using the most stringent OS security. If there is a vulnerability in one of these processes, it cannot interact with other processes, including your hard drive. This is unlike other browsers that have no separation.

If there is a vulnerability in older-style browsers, it can still interact with anything running in the current single browser process, including crashing your entire browser session or interacting with other system resources.

Just Web Browsing?
This does not limit itself to browsers. This method applies to all processes running on the system. If there is a process that is allowed to interact with other processes, then it stands to reason that it can be used for malicious purposes. Enter another utility: Sandboxie (http://www.sandboxie.com/). Sandboxie is a great utility that allows any process to run in a sandbox. If there is a vulnerability or crash in the process that Sandboxie is running, it acts in a similar manner to Chrome's renderer, it won't interact with other processes to cause wider damage.

You can close the Sandboxie process along with the misbehaving process and start over. With this (lack of) power, it is no wonder that developers are leaning on this technology to help make computing safe for the masses again. It won't be impossible to mount a successful attack, but it will be much more difficult. The downside? Look for phishing to become more popular as it will be easier to use it as a tool than to exploit the actual system. What do you think about Sandboxing when it comes to creating programs?


2010-01-18 16:17 by Tim Cronin

The content of this field is kept private and will not be shown publicly.

More information about formatting options

 
Become a fan Follow us Join us Join us Read more

Enter a feature request Join us Watch