Using the Google Chrome Sandbox [closed]

Question

There are several resources out there that explain how the sandbox in Chrome works and what it does to protect users from malicious code.

Chromium Blog
Chromium Developer Documentation
Sandbox FAQ

That's great, and I like the OS-centric design that they have in place (somewhat of a "The OS probably knows how to secure itself better than we do, so we let it" approach.) They also mention in several places that the sandbox itself was designed to not be dependent on Chrome but instead more-or-less standalone so that theoretically any process could be sandboxed as long as the architecture of the program is compatible (sandboxed code must run as it's own process as a child of a non-sandboxed parent.)

I just happen to have an application who's design makes it ripe for sandboxing, and was able to get a parent/child process working with it. I've got the Chromium code and... have no idea what to do next.

Has anyone out there actually sandboxed anything with this yet? Are there any resources that document it's usage or APIs? I would imagine it should be pretty simple, but I'm at a loss for where to start.

EDIT: My finding below in the answers!

Answer 1

Okay, so here's what I found about sandboxing code with Chrome.

First off, you'll need to go get the chromium source code. This is big, and will take a while to get, but I've yet to find any reliable shortcuts to checkout that still yeild usable results. Alos, it's very important that you follow the instructions on that page VERY CLOSELY. The Google crew knows what they're doing, and aren't keen on useless steps. Everything on that page is necessary. Yes. Everything.

Now, once you get the source, you don't actually have to build chrome in it's entirety (which can take hours!) to use the sandbox. Instead they've been nice enough to give you a separate sandbox solution (found in the sandbox folder) that can build standalone. Build this project and make sure everything compiles. If it does, great! If it doesn't, you didn't follow the steps on the build page, did you? Hang your head in shame and go actually do it this time. Don't worry, I'll wait...

Now that everything has built your main point of interest is the sandbox_poc project ("poc" = Proof of Concept). This project is basically a minimal GUI wrapper around a sandbox that will launch an arbitrary dll at a given entry point in a sandboxed environment. It shows all the required steps for creating and using a sandbox, and is about the best reference you've got. Refer to it often!

As you look through the code you'll probably notice that the code it actually sandboxes is itself. This is very common with all the sandbox examples, and according to this thread (which may be outdated) is possibly the only working way to sandbox at the moment. The thread describes how one would theoretically sandbox a separate process, but I haven't tried it. Just to be safe, though, having a self-calling app is the "known good" method.

sandbox_proc includes a great many static libs, but they appear to mostly be for the sample UI they've built. The only ones I've found that seem to be required for a minimal sandbox are:

sandbox.lib base.lib dbghelp.lib 

There's another dependancy that's not entirely obvious from looking at the project though, and it's what I got caught up on the longest. When you built the sandbox solution, one of the output files should be a "wowhelper.exe". Though it's never mentioned anywhere, this file must be copied to the same directory as the executable you are sandboxing! If it's not, your attempts to sandbox your code will always fail with a generic "file not found" error. This can be very frustrating if you don't know what's going on! Now, I'm developing on Windows 7 64bit, which may have something to do with the wowhelper requirement (WOW is a common acronym for interop apps between 16/32/64bit), but I don't have a good way of testing that right now. Please let me know if anyone else finds out more!

So that's all the environment stuff, here's a bit of smaple code to get you going! Please note that although I use wcout in the child process here, you can't see any console output when running in the sandbox. Anything like that needs to be communicated to the parent process via IPC.

#include <sandbox/src/sandbox.h> #include <sandbox/src/sandbox_factory.h> #include <iostream>  using namespace std;  int RunParent(int argc, wchar_t* argv[], sandbox::BrokerServices* broker_service) {     if (0 != broker_service->Init()) {         wcout << L"Failed to initialize the BrokerServices object" << endl;         return 1;     }      PROCESS_INFORMATION pi;      sandbox::TargetPolicy* policy = broker_service->CreatePolicy();      // Here's where you set the security level of the sandbox. Doing a "goto definition" on any     // of these symbols usually gives you a good description of their usage and alternatives.     policy->SetJobLevel(sandbox::JOB_LOCKDOWN, 0);     policy->SetTokenLevel(sandbox::USER_RESTRICTED_SAME_ACCESS, sandbox::USER_LOCKDOWN);     policy->SetAlternateDesktop(true);     policy->SetDelayedIntegrityLevel(sandbox::INTEGRITY_LEVEL_LOW);      //Add additional rules here (ie: file access exceptions) like so:     policy->AddRule(sandbox::TargetPolicy::SUBSYS_FILES, sandbox::TargetPolicy::FILES_ALLOW_ANY, "some/file/path");      sandbox::ResultCode result = broker_service->SpawnTarget(argv[0], GetCommandLineW(), policy, &pi);      policy->Release();     policy = NULL;      if (sandbox::SBOX_ALL_OK != result) {         wcout << L"Sandbox failed to launch with the following result: " << result << endl;         return 2;     }      // Just like CreateProcess, you need to close these yourself unless you need to reference them later     CloseHandle(pi.hThread);     CloseHandle(pi.hProcess);      broker_service->WaitForAllTargets();      return 0; }  int RunChild(int argc, wchar_t* argv[]) {     sandbox::TargetServices* target_service = sandbox::SandboxFactory::GetTargetServices();      if (NULL == target_service) {         wcout << L"Failed to retrieve target service" << endl;         return 1;     }      if (sandbox::SBOX_ALL_OK != target_service->Init()) {         wcout << L"failed to initialize target service" << endl;         return 2;     }      // Do any "unsafe" initialization code here, sandbox isn't active yet      target_service->LowerToken(); // This locks down the sandbox      // Any code executed at this point is now sandboxed!      TryDoingSomethingBad();      return 0; }  int wmain(int argc, wchar_t* argv[]) {     sandbox::BrokerServices* broker_service = sandbox::SandboxFactory::GetBrokerServices();      // A non-NULL broker_service means that we are not running the the sandbox,      // and are therefore the parent process     if(NULL != broker_service) {         return RunParent(argc, argv, broker_service);     } else {         return RunChild(argc, argv);     } } 

Hopefully that's enough to get any other curious coders sandboxing! Good luck!

Answer 2

I'm not sure precisely what sort of answer you want... The first thing you should do is check the Chrome Source Code reference. What interests us is this:

sandbox: The sandbox project which tries to prevent a hacked renderer from modifying the system.

Spelunking around that code, and looking for API references in the Rendering part of the Chromium could help.

renderer: Code for the subprocess in each tab. This embeds WebKit and talks to browser for I/O.

Go look around there, you can probably see how Google themselves are using their sandbox, I expect it's going to be something similar to

//Lets start up the sandbox, I'm using the Chrome Blog example TargetPolicy::SetTokenLevel() TargetPolicy::SetJobLevel() TargetPolicy::SetIntegrityLevel() TargetPolicy::SetDesktop() 

Generally this is the approach I use when meeting a new code base, check how it gets called.