
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 -

    * it is not a replacement for noscript + friends. A nasty javascript
that does something INSIDE your browser might still be able to hurt you.
The objectives of IronSuite is to restrict what an application can do to
the surrounding environment, other applications and data
    * It is not a replacement for patching. Some types of bugs are
hopefuly catched by the sandbox. Other bugs, in the interfaces that we
permit from a sandboxed program might still hurt you.
    * It will not protect against kernel bugs or bugs in the sandbox
mechanism.
    * It is not a replacement for your firewall. Other processes running
on your machine can possibly still be remotely exploitable if you does
not block them on the network.
    * It does not help you protect data-in-transit. You still need
TLS/SSL for that.
    * your privacy setting (cookies, browsing history, etc) is still
using its standard settings.
    * Last, but not least, it is not a replacement for street smartness.
You still might want to avoid that pr0n or hacking site.

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. In chrome the sandbox is used to restrict the
rendering enginge and the rendering unix process. The chrome sandbox
does not protect plugins.

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:

    * The Chrome sandbox library was developed by and for the Chrome
application. The developers have more introspection possibilities on
what the Chrome browser does. The IronsSuite sandbox is developed for
sandboxing 3rd party programs. We have no source code access or other
means for introspections of many of these applications. The only way to
know what to block or accept is to run the program in sandbox debug mode
and read the log file, adjust rule file, rinse and repeat.
   * Chrome needs to be cross platform - while it uses the same sandbox
interface as ironfox for osx (but with different rules), it still needs
to handle windows and linux - Not an easy task considering the myriads
of linux dists.
   * Chrome protects the browser(and the system) from the renderer, not
including plugins. Ironfox protects the system from the browser,
including the plugins. This is an important difference, as a compromise
of the browser still hurts (as it is used for banking and other
sensitive tasks).
    * IronSuite sanbox runs from process creation until termination.
Chrome sandbox runs from the point that the process calls LowerToken()
    * The Chrome sandbox is a C++ library distributed with the Chrome
distribution. The Apple sandbox mechanism is included in MacOSX 10.6 and
later

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 (http://www.chromium.org/developers/design-documents/sandbox)
description,
the Chrome sandbox FAQ
(http://www.chromium.org/developers/design-documents/sandbox/Sandbox-FAQ)
 and the Chrome OSX sandbox design document
(http://www.chromium.org/developers/design-documents/sandbox/osx-sandboxing-design)

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
---------------------

    * The /private subdirectories
    * /tmp subdirectories (which links to /private)
    * /var subdirectories (which links to /private)
    * Some .plist-files associated with the specific program
    * Some lock files used by the program (flaging in the file system
that some action is ongoing)
    * /dev/dtracehelper device file, used by the sandbox functionality
itself

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

    * The "Download Files" area. This is a very important point. When
you download files, you cannot save things on the desktop, in a random
subdirectory in your home directory, etc.
    * The browser cache area
    * The browser cookie database
    * The browser history database

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

    * The flash user directory, where tmp files and cookies are stored
    * The java cache
    * The java console log

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:

    * The applications subdirectory in /Application
    * Your home directory. Here we normally only allow metadata checking
on the home directory, not general process read access to files or
subdirectories contained in that directory
    * subdirectories of /Library that contain font, audio, language,
graphics drivers, etc, information
    * subdirectories of /System/Library that contain font, audio,
language, graphics drivers etc, information
    * subdirectories of ~/Library that contain font, audio, language,
graphics drivers etc, information
    * subdirectories of /private
    * subdirectories of the /var and /tmp directories that are linked to
/private

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:

    * netstat, since that is used as a source for entropy. Removing that
ability will probably render a situation where less entropy is collected
and we have broken the crypto security.

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.

Logging and debuging
==============

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.

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`/Safari5-policy.sb
/Applications/Safari.app/Contents/MacOS/Safari



