The sandbox is a C++ library that allows the creation of sandboxed processes — processes that execute within a very restrictive environment. The only resources sandboxed processes can freely use are CPU cycles and memory. For example, sandboxes processes cannot write to disk or display their own windows. What exactly they can do is controlled by an explicit policy. Chromium renderers are sandboxed processes.
The sandbox limits the severity of bugs in code running inside the sandbox. Such bugs cannot install persistent malware in the user‘s account (because writing to the filesystem is banned). Such bugs also cannot read and steal arbitrary files from the user’s machine.
(In Chromium, the renderer processes are sandboxed and have this protection. After the NPAPI removal, all remaining plugins are also sandboxed. Also note that Chromium renderer processes are isolated from the system, but not yet from the web. Therefore, domain-based data isolation is not yet provided.).
The sandbox cannot provide any protection against bugs in system components such as the kernel it is running on.
Yeah, kind of... except that to take advantage of the Java sandbox, you must rewrite your code to use Java. With our sandbox you can add sandboxing to your existing C/C++ applications. Because the code is not executed inside a virtual machine, you get native speed and direct access to the Windows API.
No and no. The sandbox is a pure user-mode library, and any user can run sandboxed processes.
We leverage the Windows security model. In Windows, code cannot perform any form of I/O (be it disk, keyboard, or screen) without making a system call. In most system calls, Windows performs some sort of security check. The sandbox sets things up so that these security checks fail for the kinds of actions that you don’t want the sandboxed process to perform. In Chromium, the sandbox is such that all access checks should fail.
Certain communication channels are explicitly open for the sandboxed processes; the processes can write and read from these channels. A more privileged process can use these channels to do certain actions on behalf of the sandboxed process. In Chromium, the privileged process is usually the browser process.
Yes. It's called integrity levels (ILs). The sandbox detects Vista and uses integrity levels, as well. The main difference is that the sandbox also works well under Windows XP. The only application that we are aware of that uses ILs is Internet Explorer 7. In other words, leveraging the new Vista security features is one of the things that the sandbox library does for you.
Yes. The sandbox does not have any hard dependencies on the Chromium browser and was designed to be used with other Internet-facing applications. The main hurdle is that you have to split your application into at least two interacting processes. One of the processes is privileged and does I/O and interacts with the user; the other is not privileged at all and does untrusted data processing.
Possibly. But it‘s worth the trouble, especially if your application processes arbitrary untrusted data. Any buffer overflow or format decoding flaw that your code might have won’t automatically result in malicious code compromising the whole computer. The sandbox is not a security silver bullet, but it is a strong last defense against nasty exploits.
Well, the main thing to keep in mind is that you should only sandbox code that you fully control or that you fully understand. Sandboxing third-party code can be very difficult. For example, you might not be aware of third-party code's need to create temporary files or display warning dialogs; these operations will not succeed unless you explicitly allow them. Furthermore, third-party components could get updated on the end-user machine with new behaviors that you did not anticipate.
For the most part, no. We recommend against using them before lock-down. Once a sandboxed process is locked down, use of Winsock, COM, or DirectX will either malfunction or outright fail.
No, the sandboxed process does not start fully secured. The sandbox takes effect once the process makes a call to the sandbox method LowerToken(). This allows for a period during process startup when the sandboxed process can freely get hold of critical resources, load libraries, or read configuration files. The process should call LowerToken() as soon as feasible and certainly before it starts interacting with untrusted data.
Note: Any OS handle that is left open after calling LowerToken() can be abused by malware if your process gets infected. That's why we discourage calling COM or other heavyweight APIs; they leave some open handles around for efficiency in later calls.
There is no master list of safe APIs. In general, structure your code such that the sandboxed code reads and writes from pipes or shared memory and just does operations over this data. In the case of Chromium, the entire WebKit code runs this way, and the output is mostly a rendered bitmap of the web pages. You can use Chromium as inspiration for your own memory- or pipe-based IPC.
Yes, it might, if there‘s a bug there. The key point is that it’s easier to write and analyze a correct IPC mechanism than, say, a web browser engine. Strive to make the IPC code as simple as possible, and have it reviewed by others.