Sandboxing treats the renderer as a hostile process which at any time can be compromised by a malicious attacker via buffer overruns or other such attack vectors. Once compromised, the goal is to allow the renderer access to as few resources of the user's machine as possible, above and beyond the standard file-system access control and user/group process controls enforced by the kernel.

See the overview document for goals and general architectural diagrams.

On Mac OS X, individual processes can have their privileges restricted using the sandbox(7) facility of BSD, also referred to in some Apple documentation as "Seatbelt". This is made up of a single API call, sandbox_init(), which sets the access restrictions of a process from that point on. This means that previously opened file descriptors continue working even if the new privileges would deny access to newly created descriptors. We can use this to our advantage by setting up everything correctly at the start of the process then cutting off all access before we expose the renderer to any 3rd party input (html, etc).

Mac OS X, on Leopard, supports five constants for sandbox access restrictions:

• kSBXProfileNoInternet  - disables TCP/IP networking.
• kSBXProfileNoNetwork - disables all sockets-based networking
• kSBXProfileNoWrite - disables write access to all filesystem objects
• kSBXProfileNoWriteExceptTemporary - disables write access to filesystem objects except /var/tmp and `getconf DARWIN_USER_TEMP_DIR`
• kSBXProfilePureComputation - all OS services are restricted

In the renderer, we would probably want to use a combination of kSBXProfileNoNetwork and kSBXProfileNoWrite. If possible, we would like to get by with kSBXProfilePureComputation, but the some of the API calls that we need to make for font and graphics rendering may not work in that mode. We'll have to experiment. We will also have to experiment with out-of-process plug-ins, which are not heavily sandboxed on Windows. The Mac implementations of the same plug-ins may be different enough to allow stronger restrictions.

Contrary to proposed sandboxing solutions on Linux, Seatbelt does not place restrictions on memory allocation, threading, or access to previously opened OS facilities. As a result, this shouldn't impose any additional requirements or drastically alter our IPC designs. 

OS X provides additional protection against buffer overflows. In Leopard, the stack is marked as non-executable memory and thus less susceptible as an attack vector for executing malicious code than the same code on Windows. This doesn't prevent against buffer overruns in the heap, but for 64-bit apps, Leopard disallows any attempts to execute code unless that portion of memory is explicitly marked as executable. As we move towards 64-bit render processes in the future, this will be another attractive security feature. 

Note that using this mechanism would restrict Chromium to only running on Leopard and higher. We could run renderers on Tiger without sandboxing, but that would be unwise from a security perspective.