Design philosophy behind the IronSuite

We all use network based applications all day long: web browsers, instant messageing clients, mail readers, streaming media players, games, etc. They have become a central part of all Internet users life. One problem with them all is that they might be vulnerable for different types of attacks. One attack type is to craft malicious data (a movie, an url, etc) that will be threated as executable code by the receiving end. This has become standard operating procedure by attackers and is done by exploiting bugs in the graphics engine, the XML parser, the input buffer in some program, or similar means.

We believe that one large and important attack trend, since several years back, has been on server-to-client attacks. A too common example is a hostile web site, malicious or a victim by themself, can inflict harm to your browser. We developed IronSuite because we want to be able to use web browses, IM software et al with a reduced fear that the next site I visit will have an infected banner ad that pwns my machine.

By using sandbox mechanism, the attack surface of a specific MacOSX application should be lowered by restricting that application to a minimum of system level interaction (e.g. file reads, process creation, etc). Network-savy applications face the risk of beeing remotely exploited by stack smashing attacks, heap corruptions, getting injected malicious javascript or other malicious code.

The sandbox technology used by Apple is built on a domain specific control language based on the well-known Scheme language. By writing specific Scheme constructs one can restrictor permit a specific system call, or specific parameters to that system call.

The general idea behind IronSuite is to act as an additional barrier, in case any existing protection mechanism fails, and prevent the controlled program from misbehave. e.g. read files that should be protected (e.g. the web browser controlled by an injected program by a buffer overrun could steal pgp keyring or documents or the users mailbox).

What does it NOT do

One important limitation that all IronSuite protected tools have, is that they cannot update themself while running in sandboxed mode. This is because they do not have write access to the /Application directory or subdirectories there. This is important to know, since it is a design choice to limit the possibility for an attacker to manipulate your program and configuration. The drawback is that updates have to be done outside the sandboxed mode, e.g. close program and then download updates manually and install. Or temporarily restart the program without the IronSuite sandbox, use the built-in update feature, restart again into sandboxed mode.

So be aware. An updated program certainly can have change its internal structure and have added features which the sandbox blocks, so the program can start to misbehave.

There are no such thing as a catch-all security solution, so, to be very clear -

A different packaging of the IronSuite concept is available for MacOSX Tor users. That bundle have the additional objectives to ensureing the users privacy, and thus is more picky on what is read from the file system and work hard to not leave a footprint on the installed system.

IronSuite browsers (IronFox and IronSafari) vs Chrome

A very simple question is to ask what is the differece between using Googles Chrome browser and the browsers developed in the IronSuite project? The major difference lays in where the sandboxing is performed.

Chrome is a program running as a number of collective processes on the computer. One of these processes perform the actual rendering of the finished web page. Each of these processes needs to be protected separately.

The the sandboxes that the IronSuite project have developed for the Firefox and Safari browsers will sandbox the complete browser. Including any add-on programs, components, subsystems, etc that is started from that browser. So a quicktime player or a pdf viewer started by safari will inherit the sandbox restrictions, thus a bug triggered by a malicious PDF or a maliciously crafted movie, will not be able to access your computing environment. But this might also be a problem, since a plugin might not run as anticipated, especially if it has not been tested and rules have been created for it by the IronSuite crew or by yourself.

Some other important differences between Chrome and the IronSuite approach include:

However, the mac port of the Chrome browser actually use the Apple Sandbox Policy Language. Searching for files installed by Chrome in /Applications/Google Chrome Framework.framework/Resources will show:

Besides the MacOS specific details for the Mac implementation of Chrome, one real advantage that the Chrome sandbox have over the IronSuite approach is that Google has implemented their sandbox as a portable C++ library that can be used on many platforms. The IronSuite sandboxing only works on Apple MacOSX since it is just custom sandbox profiles using the sandboxing feature in the OS.

More information on the chrome sandbox can be found Chrome sandbox design description and in the Chrome sandbox FAQ

File system access

For applications that need to access the file system for saving data, the parts of the file system that should be accessible, should be restricted and deterministic.

There are difference on how tightly one can control operations such as file write, file read, file read metadata, file read extended attributes. Several component libraries and MacOSX functions seem to show lots of odd behaviour, such as stat-ing various libraries and standard files. Removing access to these would lead to strange and sometimes unknown side effects.

File creation and file write

For a web browser, file creation should only be allowed in:

In addition, file creation is also allowed for various plugins, such as flash and java. These directories include:

File read and file metadata read

There is a difference between letting a process checking the file metadata and letting it read the file content. Where possible, we restrict access to reading metadata, not content

There is alot of files, and even more directories, that needs to be checked when running any MacOSX program. File reads are done all over the place. SOME of those places and files include:

Process creation

No additional processes should normaly be allowed. Only very specific well-known subprocesses should be allowed.

Some subsystems, add-ons and plugins such as flash support and java runtime support is to be allowed by a sandbox controlled process. The same restrictions are inherited by these subprocesses, so certain flashbased programs or java programs might break since they might require additional system access, e.g. writing certain files.

For IronFox that should be:

We seriously consider this a bug in the firefox implementation for MacOSX. The operating system provides /dev/random and /dev/urandom, but obviously firefox uses this weird netstat output as antrophy anyway.

This also highlights some of the problems with doing our approach to 3rd party sandboxing. If we not had have the opportunity to check the NSS library source code, we would probably had denied netstat to run, and thus probably robbed firefox its source for entrophy.

Interprocess communication

Unix signals are normally allowed only to be sent from the process to itself.

Lots of communication is happening with the MACH subsystem. This is because apple have several interacting subsystem and service functions that all need to cooperate that way, e.g. font handling, cut-and-paste functionality, language support, sound and multimedia support, etc.

Network access

For programs not needing network access, no incoming or outgoing network access should be allowed.

For processes needing inbound network traffic, only well-known network ports should be allowed.

For processes needing outbound network traffic, only well-known network ports should be allowed.

Shared sandbox profiles

When a generic sandbox profile is used for inclusion by other profiles, the definitions and controls used there should be as restrictive, not permissive, as possible. At ROMAB we try to find common policy code segments and extract them to a file containing common profile rules that can be shared between the different tools we harden.


We believe that there is little or no performance penalty for running programs in sandbox. The text file containing the is compiled into a binary format when a profile is used the first time. This binary is then saved and cached for efficient handling by the operating system.

Logging, debuging and customizations

The sandbox protected tools will normaly log any policy violations to the normal system log (/var/log/system.log) with all violations getting the "sandboxd" prefix.

      Jun 15 14:04:48 mbp sandboxd[5126]: Adium(5282) deny file-read-metadata /Users

To debug any problems with IronSuite protected applications, start to examine the system log file, for example by filtering out the last blocked system calls.

     tail -100 -f /var/log/system.log  | grep sandboxd

Please be vary that the log file will most certainly show several lines of logs with error messages. Several of those blocked system calls, e.g. file access that we have analysed and considered non essential. Ergo, the log file can be noisy and filled with crap.

To debug one of our sandboxes, start it directly from the command line with the command sandbox-exec with the appropriate options. Plese note that sandbox-exec is very picky. One have to give a complete and absolute path to the sandbox profile and the executed binary!

    $ sandbox-exec -f `pwd`/ /Applications/

We are very interested in any comments, bug reports, extensions and enhancements that you or someone else might create. please send those to:

Users of the IronSuite should be able to customizations from the release, e.g. if someone wants to use an addon that we have not used or tested when we developed the initial sandbox profile.

The way to do customizations is simple: running the program, using that extra feature, examine the logfile, update the rule set, rinse and repeat.

This is also why we use the 2 clause BSD license, if someone want to release their stuff to the world. We would certainly appretiate if people would mail us their customisations, and we might be able to redistribute them.