IronSuite - Frequently Asked Questions

1.0 Sandboxing technology

1.1 What is this sandboxing technology?

Sandboxing is a method to restrict what a running program - a process - can do to your computing environment. By blocking certain operations, such as file creation, file reads, execution of new programs, interprocess communication, subsystem access, it is possible to handle a program that has gone rogue.

It is really important to understand that a sandbox can limit the damage an attacker can cause, but the sandbox cannot prevent those attacks.

The reasons for a process to start to misbehave is multiple, but one primary reason is to accept untrusted input. The input can be a filename that was not expected by the developer of the program - now the rogue program will read an otherwise protected file (password database, certificate store, sensitive document, etc) or overwrite a file to change the system behaviour (replacing a program binary, adding an loginname to the user database, etc)

Another way of looking at it - sandboxing is a whitelisting technology where the sandbox policy developer decides what system calls a certain application is allowed to use. And with what parameters these system calls are can be called with.

An important concept to understand, is that a sandboxed process that creates a sub process by default will have the sub process inherit the sandbox restrictions of their parent.

Google is currently heavily researching and using sandboxing, e.g. by using it in the google chrome web browser.

For more information, see the wikipedia description of sandboxing

1.2 Is Apple using this sandboxing technology somewhere?

We have not found any evidence that Apple is currently really using the process sandboxing in their desktop version of MacOSX 10.5 or MacOSX 10.6.

However, according to the MacOSX Server documentation and some example files available in the directory /usr/share/sandbox Apple seem to apply sandboxing to some background system daemons starting in MacOSX Server 10.5. These processes includes the kerberos server, the ssh daemon, ntp server, xgrid daemon, etc.

If one looks in some of the startup files used by the system launchdaemon, launchd, one can find some traces, such as:

Apple is apparently using sandboxing on their mobile devices, iPhones, iPads, etc, as can be seen by by this bug filing, CVE-2010-1751, where the sandbox configuration was in error.

You can find more on MacOSX Server sandboxing on page 31 in the server security documentation.

Since we have not found any documentation online or elsewhere, we have written up a description of the SandBox Policy Language, SBPL here.

1.3 How does the MacOSX Sandboxing work, more specificly?

The sandboxing of an application will lead to a situation where you have mandatory access control enforced by the operating system on the process itself.

The process is started in a special way, where the launching mechanism signals to the operating system that this process is going to be runned in a sandbox. This is either done from the command line by using the "sandbox-exec(1)" tool, or by the process itself by calling the "sandbox_init(3)". The sandbox policy is a text file that gets compiled into binary file. There is a library called /usr/lib/libsandbox that incorporate a Scheme compiler, there is a system daemon called "sandboxd(1)" which is an entrypoint into the kernel. The dynamic kernel module is called "" that will control, according to that sandbox policy rule file, how that process is going to execute.

1.4 Will this sandboxing hurt my systems performance?

We belive that there is little or no overhead in using the sandboxing feature. For any normal usage, such as browsing the web, chatting via a instant message client, etc.

When we get some hard numbers, we will publish them here.

1.5 What security problems does sandboxing not solve?

We focus on certain aspects on protection - to avoid someone else than you to manipulate software that you use, to control in ways you do not want.

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

To be very clear - we certainly anticipate the day where someone will publish exploits that will let the attacker escape the Apple sandbox, e.g. by using multi-bug payloads in the attacks, exploiting low-level hardware bugs, exploiting kernel or driver bugs, etc. Until then, we hope that the path of using sandboxing is at least better than running unsandboxed programs.

1.6 What potential problems will sandboxing introduce?

There are several problems. One problem, when developing sandboxes for 3rd party binary applications, is that you as a sandbox developer have little or no knowledge of the internal workings of the program itself. By blocking a systemcall, such as reading or writing a file, the internal modus of a program can be altered.

The sandboxing itself introduces new attack surfaces, such as APIs, kernel modules, system daemons, as well as alot of more code which an attacker can attack.

To be very clear - we certainly anticipate the day where someone will publish exploits that will let the attacker escape the Apple sandbox, e.g. by using multi-bug payloads in the attacks, exploiting low-level hardware bugs, exploiting kernel or driver bugs, etc. Until then, we hope that the path of using sandboxing is at least better than running unsandboxed programs.

1.7 Can those MacOSX sandboxes be used on iOS?

We dont know how the iOS internals or execution environment works, so its hard to answer that question, but in general the answer is "no", since it is another operating system. That beeing said, there is a sandbox concept on Apples mobile devices, but that sandbox feature appears to be somewhat different.

2.0 The IronSuite Project

2.1 What is the IronSuite project?

A project to develop sandboxing profiles for a number of common Internet aware applications in an effort to raise the security and protection against a number of common attacks that could manipulate the application.

2.1.1 Who is behind the IronSuite project?

The project currently consists of Andreas Jonsson, Tobias Norrbom and Robert Malmgren from ROMAB

2.2 What are the objectives of the IronSuite project?

The objective is to harden a number of standard internet applications, such as web browsers, instand messageing clients, streaming media clients, etc.

Chris Evans from Google put it quite elegantly - "The browser ecosystem is at the forefron of the war". That is why we have decided that we need another level of defense, since attackers are out to find bugs in browsers, browser plug-ins, helper object, etc.

2.3 Will the project be Apple specific, or do you consider sandboxing applications on other operating systems?

In general no. We have plans to add non-Apple sandboxed profiles in the future, for example by using Linux AppArmor profiles to sandbox Linux applications. But for the moment, we are focusing on MacOSX. If you are sitting on good policy files for some other operating system and sandboxing technology, please contact us and we'll discuss.

2.3.1 How to do sandboxing on the Linux operating systems?

There are several ways:

2.4 Under what license do you distribute IronSuite?

We distribute everything under simplified 2 clause BSD license. That gives anyone maximum flexibility. See the license file below. This is included in all our sandbox profiles.

;; MacOSX Sandbox profile for the program 
;; Copyright 2010 Robert Malmgren AB. All rights reserved.
;; Redistribution and use in source and binary forms, with or without modification, are
;; permitted provided that the following conditions are met:
;;   1. Redistributions of source code must retain the above copyright notice, this list of
;;      conditions and the following disclaimer.
;;   2. Redistributions in binary form must reproduce the above copyright notice, this list
;;      of conditions and the following disclaimer in the documentation and/or other materials
;;      provided with the distribution.
;; The views and conclusions contained in the software and documentation are those of the
;; authors and should not be interpreted as representing official policies, either expressed
;; or implied, of Robert Malmgren AB.

2.5 How can I support the IronSuite project?

You can get involved in the project:

2.6 I have developed a cool sandbox profile for application FOO. Are you interested in including it in the IronSuite?

If you have developed something, please mail that profile to us. We will check it, if it tight enough - one can write sandbox profiles that is too open - and if it can be made to work with our include files, startup files, etc, and we will add it to the distribution.

To submit any profiles, please e-mail them to:

Since the IronSuite is a community project, sharing your profile is a really good thing.

2.7 I have found a bug in one of your sandbox profiles, what do I do?

We would happily accept any bug reports that you find! But first we would really know if it is a bug that you have found. It might be an intentionally restricted feature - that is why we developed IronFox.

Please send any bug reports to

2.8 What design criterias have you choosen while developing sandboxes for the applications?

See the rather long description about that in our IronSuite design philosophy description document, that is available on the web.

2.9 OK, this IronSuite stuff looks awsome, but I really dont trust you guys, is there a way that i still can use it?

Yes there are ways you still can benefit from our sandboxing project, even if you dont want to follow the Iron*-path.

We distribute some scripts and binaries that comes with the application bundle. If you dont trust binaries downloaded from the internet, or you think our scripting skills suck big time, you can take our sandbox profiles, edit them to hard code some things that our scripts treat as variables, and run that sandbox profile by hand from the commandline. The syntax for that would be like:

     sandbox-exec /path/to/ /full/path/to/executable/including/subpaths/to/.app/catalog

And for a real-world example, that could be

     sandbox-exec /Applications/ /Applications/

But remember that type of manual execution require that you edit the sandbox profile and change things like %%username%%, %%tmpdir%% and %%PATH%% in the .sb-file.

2.10 Is there a mailing list for IronSuite, IronAdium, IronFox, etc?

Yes, we have a mailing list called ironsuite-discuss where all things related to our sandboxing effort and the tools are discussed.

Please send a mail to

to request your membership.

3.0 The IronSuite tools

3.1 IronFox - the Firefox 3.6 wrapper

Ironfox is our sandboxed version of the firefox web browser. As a security caution, we have locked down firefox to not be allowed to read and write files all over the place, (in general) not be able to spawn sub processes, not be able to do IPC with lots of Apple subsystems and components, etc.

If you are interested in using the sandboxing protection that Ironfox offer, you can download ironfox here

3.1.1 What known limitations or bugs are there in IronFox?

IronFox is known to work with firefox up to 3.6.3. Firefox 3.6.4 is changed quite substantially under the hood, where they introduce something called out-of-process plugins (OOPP). These types of big changes will certainly be blocked by the ironfox ruleset. We will develop and test new versions of ironfox with this and later firefox releases.

The Ironfox sandbox might not work with all firefox plugins. It is known to work with noscript.

3.1.2 Is it possible to add directories, custom ones, from which IronFox can upload files from (besides its Downloads folder)?

It is. Maybe we will add this in the future in the default installation; ie /User/<username>/iron-uploads or similar. In the meantime, it is quite trivial to edit the policy to add it yourself.

The file you want to examine and edit is /Applications/

3.1.3 I have heard that you have a special version of IronFox for the Tor browser bundle. Why? and what is the difference?

While the objectives of the IronFox and the IronSuite is to protect you and your computing environment, the Tor project have some additional objectives. They want to protect the users privacy, and in some ways to the extent that any ordinary firefox user would find some of their privacy prioritations too restrictive for their web browsing experience.

For example, the version of the firefox sandbox included with the Tor browser bundle have the additional restrictions:

3.1.4 Are there any example of attacks that the IronFox browser blocks?

A maliciously crafted java/flash/javascript program that would try to steal information from your hard disk, e.g. your pgp key chain.

3.2 IronAdium - the Adium 1.3 wrapper

We have a wrapper for the wellknown Adium instant messageing client. Adium was one of the many IM clients that where hit by the bug in libpurple, a general library that implements many of the popular IM protocols. Sandboxing Adium would be one way of protecting that types attacks from having severe consequenses to you.

If you are interested in using the sandboxing protection that IronAdium offer, you can download IronAdium here

3.2.1 What known limitations or bugs are there in IronAdium?

The IronAdium 0.2 will not support file transfers. There might be protocols besides the 3 we know to work (ICQ, MSN and XMPP/Jabber) that will not work.

3.2.2 When will there be support for Adium 1.4?

First off, the Adium 1.4 client is just a release candidate. Things can still change inside that program, so we would prefer to have a real release before we release our sandbox. That said, we will work on creating a sandbox for 1.4 as soon as we have time for that

3.3 How do we know that there are unaltered distributions; or what is the IronSuite project GPG/PGP signing key?

We sign our distributions with the encryption software Gnu Privacy Guard, GPG where we use a specific key dedicated for our software distribution. The gpg signature is available as a separate file, e.g. ironfox-0.x.y.tar.gz.sig, that you download separate. By downloading both the program distribution itself as well as the signature file, you can automatically check that the program is distributed by us, as well as that the software has not been altered by anyone from the time we signed the file. The fingerprint and all other

     pub   1024D/D3709435 2010-06-21 [valid to: 2015-06-20]
     Key finger print = B6B0 4AF1 CDE5 3B40 BBE0  6868 36F8 2B7B D370 9435
     uid                  ROMAB software signing key <>

Use the command

     gpg --verify ironfox-0.x.y.tar.gz.sig

to verify the file.

We also use the ``shasum'' command to generate a checksum, that is printed on the web page from which you download the software.