Take a look at the applications you use most on your computer. More than likely, a good number of them offer highly-connective functionality, most notably your web browser. These highly-connective programs can do a lot, but they’re also an open invitation for bad hackers to strike.
To prevent strikes from becoming successful, a developer would have to spot and close every single hole in their code, which simply isn’t possible. Instead, developers have to take that fact and plan their code with that in mind. The most common and effective solution: a sandbox.
Sand In A Box?
No, it’s not the local park sandbox I’m preferring to, but software sandboxes. These sandboxes have one key purpose: to prevent the spread of an attack. As I mentioned above, smart developers know that code isn’t perfect, and that their product will eventually be hacked into or otherwise penetrated. In order to protect the user, they implement a sandbox which isolates parts of their program. In essence, everything that happens in a sandbox, stays in that sandbox.
Sandboxes In Action
In order to explain sandboxes in action, I’ll use Google Chrome as the primary example. Chrome is one of the most prominently known products to implement sandboxing, which Google proudly touts as a unique security feature among browsers. Google took Chrome and essentially split it into three different categories: the main process which ties everything together, the tab process(es) which hold the pages and include the renderer, and the plugin process(es). All of these categories have different permission levels so that they’re able to run, but those permissions are the bare minimums so that all of them are pretty constricted. Additionally, the different processes can’t really talk to each other, but just co-exist. For example, although Flash content from the Flash plugin may be present on a page, the processes are still separate and don’t talk to each other. The renderer only leaves a space on the page for that process to be displayed. This inability to communicate is important because if a tab crashes or is hijacked, it can’t affect the other tabs nor the system itself.
Firefox Has It Too, Sort Of
Firefox also has a sandboxing feature, although limited, separating it from third-party plugins like Flash. While the browser as well as all of its tabs are combined into a single process, there is a separate process for all plugins. In Firefox’s approach, it places more trust in its own code than Googles does with Chrome, and puts the blame for any browsing issues on plugins. Therefore, if the plugins crash in whatever way, the browser and the tabs aren’t affected.
Thinking Outside The Box
While it’s a good strategy to have sandboxing techniques implemented into a program’s code itself, there are plenty of other programs which don’t have any sandboxing whatsoever. Instead, you’ll want to run a virtual sandbox where you can run programs which can only wreak as much havoc as they can inside the sandbox, leaving your system in tact. While this is often meant for testing software, it’s also a good choice to run a web browser or really any other software in there if you’re rather paranoid (or insert your other favorite word here). A very popular choice for this is Sandboxie, but there are other products, both free and paid, which can achieve the same.
Sandboxing is currently one of the hottest topics when it comes to security, and it’s definitely doing the job pretty well. Of course, developers should always still concentrate on making their code as good as possible, but it definitely doesn’t help to have some plans of action for when a problem does occur. Be advised that sandboxes still aren’t perfect, as Chrome’s sandbox was defeated in Pwn2Own 2012 after some extremely difficult hacks, but they’re definitely a much better choice than none at all.
What’s your opinion of the sandboxing applications? What improvements would you like to see in sandboxing web browsers, or which applications do you think need sandboxing? Let us know in the comments!
More articles about: