Script: sandfox

«Downloads

Download Links:	Script: download – browse – authenticate – instructions Debian/Ubuntu: packages – PPA Arch Linux: AUR
Description:	Runs Firefox and other apps in a sandbox, limiting their access to the filesystem
Recommended For:	Linux
Requires:	inotify-tools lsof
License:	GNU GPL v3     * SEE DISCLAIMER *
Related:	kscrubber
News:	What’s New?
Feedback:	comments – issues

Contents

• Overview
• Profiles And Binds
• Getting Programs To Run Well In A Sandbox
• Securing SpaceFM
• Examples
• How It Works
• Installation Instructions
• Startup Scripts – Create A Sandbox At Boot

Overview

Sandfox runs programs within sandboxes which limit the programs’ access to only the folders you specify. Programs and their child processes, like Firefox plugins, Flash, and Java, are only able to access files within the sandbox. Sandfox supports the use of custom profiles which determine what folders and files are included in each program’s sandbox, and includes default profiles for Firefox, Skype, and Google-Earth. Sandfox can create separate sandboxes for each program, or can run multiple programs in one sandbox. Programs are run in a chroot jail as a normal user, providing a substantial level of security. Sandfox is designed to be very easy to use. It handles the details for you while still giving you the ability to construct custom sandboxes easily.

Why run Firefox or other programs in a sandbox? In the Firefox example, there are many components running: Java, Flash, and third-party plugins. All of these can open vulnerabilities due to bugs and malicious code; under certain circumstances these components can run anything on your computer and can access, modify, and delete your files. It’s nice to know that when such vulnerabilities are exploited, these components can only see and access a limited subset of your files. In the case of Skype and Google-Earth, these programs contain closed source binaries (no one knows what they contain). As discussed in Fear Not Root, the root mechanism in Linux offers very limited protection for your PC and data. Sandfox uses the power of the root mechanism to protect not only system files, but all of the files you choose to protect.

sandfox --help Usage: sandfox [OPTIONS] [COMMAND [ARG]...] Runs COMMAND as a normal user within a chroot jail sandbox with limited access to the filesystem. Supports profiles for apps and includes a default Firefox profile. Must be run as root when creating sandbox. Examples: sudo sandfox firefox # Runs Firefox in a sandbox sudo sandfox bash # Shell to explore a sandbox OPTIONS: --bindro TARGET Include TARGET (a file or folder) in the sandbox bind-mounting it as a read-only filesystem --bind TARGET Include TARGET (a file or folder) in the sandbox with same ownership and permissions when possible --copy TARGET Place a disposable copy of TARGET (a file or folder) in the sandbox --hide TARGET Include TARGET (a file or folder) in the sandbox by bind-mounting an empty file or folder onto it Effectively hides the real TARGET from the sandbox Also provides a writable dummy folder --profile PROFILE Load PROFILE (a profile name or pathname). By default profiles are stored in /etc/sandfox --make Force creation or update of a sandbox (make is implied if you specify binds or profiles) --sandbox NAME Specify name of sandbox to use, create, or update --close NAME Unmount and remove sandbox NAME --closeall Unmount and remove ALL sandboxes --status Show the status of all current sandboxes --shell Run COMMAND in a shell and wait. Requires root. (bash is always run in a shell) --user USERNAME Run command as USER in the sandbox - useful if auto-detection does not work or to override --profilefolder FOLDER Use FOLDER instead of the default profile folder IMPORTANT: should be root owned & write-protected --logfile LOGFILE Also append messages to LOGFILE. sandfox daemons will also update this file provided it is accessible from within the sandbox. --verbose Provide detailed feedback --quiet Minimize output messages NOTES: OPTIONS must precede COMMAND; you can also use OPTION=VALUE; binds are processed in this order: bindro bind copy hide; missing binds are ignored; if a profile for COMMAND exists it will be automatically loaded; default profile is always loaded; profiles may contain any options valid on the command line; if COMMAND is omitted, a sandbox will be created for use.

In order to create, modify, or close sandboxes, Sandfox must be run as root, which enables it to mount filesystems as root and create a secure chroot jail that a normal user cannot break out of. Once the sandbox is created, you may run Sandfox as a normal user in order to start programs within the sandbox(es). Sandfox always runs programs as a normal user in the sandbox, even when you run Sandfox as root.

For example, to build a sandbox for Firefox and start Firefox running in the sandbox, close all running windows of Firefox, then:

sudo sandfox firefox

(sudo indicates ‘run this command as root’ – sudo is not specifically required)

Sandfox has a default profile for Firefox, so it will automatically load that profile. The profile tells Sandfox how to build a sandbox which provides the system and user folders that Firefox requires. (For full functionality of your version of Firefox, you may want to edit this profile to add more folders and files. The profile is stored in /etc/sandfox/firefox.profile) Tip: If “Save Page As…” and “Save Image As…” don’t respond in Firefox, go into Edit|Preferences|General|Downloads and set “Save files to…” a folder which exists in the sandbox.

IMPORTANT NOTE: Be sure to close all running instances of Firefox before running Firefox in a sandbox. If you don’t, then when you or Sandfox starts Firefox, the already-running instance will simply open another Firefox window, which will not be sandboxed. You can always test if the Firefox window you’re using is running in the sandbox by entering “/” as the URL in Firefox and pressing Enter. If you are able to navigate your complete filesystem, and all of your home folders appear, then Firefox is not running in the sandbox.

Sandfox can also start additional programs in the sandbox. For this, you may run Sandfox as either a normal user or as root. For example, to start Speedcrunch in an already-created sandbox:

sandfox speedcrunch

If you would like to explore a sandbox using the shell, you can run bash. Running a program in a shell requires you to run Sandfox as root. For example:

sudo sandfox bash

You will note that not all folders exist when you are in this shell, and not all programs may run properly due to missing files. When you are done with the shell, enter “exit” to return to the non-sandboxed shell.

When you are done with the sandbox, close all programs running in the sandbox, then run

sudo sandfox --closeall

This closes all sandboxes. It is recommended that you close all sandboxes before rebooting in order to avoid any shutdown delays.

Profiles And Binds

Profiles are text files in /etc/sandfox which tell Sandfox how to build sandboxes. The “default” profile is always loaded. Other profiles are loaded if the name of the profile is the same as the command you run when you create the sandbox. For example, “sudo sandfox firefox” will automatically load the firefox profile (as well as the default profile) when building the sandbox. You can edit the profiles in /etc/sandfox, and you can create your own.

Any option valid on the command line can also be placed in a profile (in the form OPTION=VALUE). You can also design a profile to include other profiles using the “profile=” option within a profile.

Profiles (and/or the command line) contain four types of options (binds) which define what files and folders appear in your sandbox.

bindro and bind
bindro=target and bind=target (where target is the full pathname of a file or folder) cause Sandfox to bind-mount the target into the sandbox’s filesystem. A bind-mount is similar to a link – it makes the folder or file accessible without actually copying any files. Unlike a link, programs see the bind-mount as an actual file or folder. The only difference between bindro and bind is that bindro makes the target a root-enforced read-only filesystem in the sandbox, whereas bind gives the target the same read/write permissions and ownership in the sandbox that it has in the original filesystem. Unless your program needs to modify files in a folder, it is best to use bindro for greater security. When files in a bind folder are modified, the files in the original filesystem are modified.

copy
Copy is used to place a disposable copy of the target into the sandbox. If these files are deleted or modified in the sandbox, it will not effect the original target. Copy provides a way to give a program read/write access to a file or folder which you don’t want changed in the original filesystem.

When copying a folder, Sandfox will bind-mount a tmpfs filesystem (aka ram drive) into the sandbox and copy the files to it. This allows you to copy a folder which may already exist in the sandbox – the bind-mount will make the original invisible. However, note that each tmpfs is limited to 100MB and consumes memory instead of disk space (this limit can be adjusted by changing “tmpfslimit=” in the script). Thus copying large folders is not recommended – this is primarily intended for small config files and the like. For larger folders, consider manually making a copy in the original filesystem first, then binding the copy.

When copying a file target, the file is simply copied into the sandbox. However, a copy directive will be ignored if the file already exists in the sandbox. Thus unlike a folder, you cannot copy a file onto its sandbox version using copy. To do so, consider manually making a copy in the original filesystem first, then binding the copy.

bind, bindro, and copy directives whose targets do not exist in the original filesystem when the sandbox is created are silently ignored by Sandfox.

hide
hide will bind-mount an empty file or folder into the sandbox. This has several uses. For one, it can hide a subfolder. For example, if you bind /var but don’t want /var/tmp to be accessible, you can hide /var/tmp. Likewise, you can hide a single file within a bind folder. Another use of hide is to create an empty folder for a program to use, rather than the original. Unlike bind, bindro, and copy, the target of a hide need not exist in the original filesystem for it to be added to the sandbox.

When hiding a folder or a non-existent target, a tmpfs filesystem is bind-mounted into the sandbox. When hiding a file, /dev/null is bind-mounted onto a file in the sandbox. If the file or folder already exists in the sandbox, it is thus hidden.

Order And Layers
Sandfox always processes all bindros, then binds, copies, and hides in this order. Note that a sandbox may consist of layers of binds, as in the /var/tmp example above.

Order is important because, for example, if you (read-write) bind your home folder, then bindro a subfolder, the subfolder WILL be read-write accessible (the bindro is performed first and the bind is laid over it). In this case you may want to bindro the home folder and bind subfolders and files which you want to be read-write accessible. It is helpful to test the sandbox filesystem you create before relying on its behavior.

If the same binds appear in multiple loaded profiles or on the command line, they will only be mounted once. Thus profiles may safely have some overlap in terms of binds.

The variable “$user” can be used in profiles (but not on the command line) to represent the sandbox user when the sandbox is created. Thus “bind=/home/$user” will bind the sandbox creator’s home folder. You can see an example of this in /etc/sandfox/firefox.profile

In addition to binds in the default profile and your profiles, Sandfox may also bind a few programs which it requires to run in the sandbox, such as /usr/bin/inotifywait.

Getting Programs To Run Well In A Sandbox

Sometimes it takes a little research to determine what folders and files a program needs to run successfully in a sandbox. While it is best to make the final sandbox as constrictive as possible, it can be helpful to use a more liberal sandbox initially. Also note that many programs, such as Firefox, will write useful error messages to stdout. Normally, Sandfox does not display the stdout messages, but you can tell it to do so by including the “––verbose” option.

Include “––verbose” when you create the sandbox, then leave that shell open and check it for messages. Even if you start additional sandboxed programs from another shell, their stdout messages may be displayed in the original shell that created the sandbox. (This is because when Sandfox is run without root, it uses a daemon to start programs inside the sandbox.)

For example, with no sandbox open, create an initial sandbox with:

sudo sandfox --verbose firefox

Leave that shell window open. You may see some messages from Firefox in it. Now close Firefox, and open a second shell window. As a normal user run:

sandfox firefox

Firefox should start again (running in the sandbox). Any stdout messages will appear in the first shell window.

Another method for capturing stdout from sandboxed programs is to redirect stdout to a file. Just note that the file must be writable from within the sandbox. For example:

sandfox "ls / > /tmp/ls-output.txt"

The quotes are required. /tmp/ls-output.txt should contain a directory listing of the / folder within the sandbox.

You can also start programs in shell mode to see their output:

sudo sandfox --shell ls /

Or, just start a shell and run programs from within it:

sudo sandfox bash

You can use /etc/sandfox/firefox.profile as a starting point for building your own custom sandboxes, as it includes many of the folders commonly required.

Also, the inotifywait program can be used directly to see what files are accessed and/or changed while a program is running. For example, to see what files in user‘s home folder are being accessed, open an extra terminal window and leave this running:

inotifywait -rm /home/user

 
Firefox Themes
The firefox profile binds most of the files needed for your KDE and Gnome themes to work in Firefox. If not, try running ‘env’ in a shell as user, and examine the values of these variables: GTK2_RC_FILES GTK_RC_FILES XCURSOR_THEME Files or folders listed in those variables may need to be binded for themes to work.

Securing SpaceFM

The SpaceFM File Manager allows scripts and programs run by the same user to interact with its socket to run custom commands and get information about currently shown tabs. Although SpaceFM will not normally accept socket commands from within a Sandfox sandbox, it is possible (though difficult) for a specially crafted program to do so, which would allow such a program full access to the filesystem outside of the sandbox. To secure sandboxes so there is no access to SpaceFM’s sockets, use of a custom SpaceFM tmp folder is recommended.

First, create a custom tmp folder for SpaceFM at boot time. For example, add the following lines to the /etc/rc.local file (add these lines before the ‘exit’ line in that file):

    mkdir /tmp/spacefm-temp
    chmod ugo+rwx,+t /tmp/spacefm-temp

Also run the above commands once now as root to create the directory for immediate use, and kill all running instances of SpaceFM:

    mkdir /tmp/spacefm-temp
    chmod ugo+rwx,+t /tmp/spacefm-temp
    killall spacefm
    rm -rf /tmp/spacefm.tmp

Next, edit /etc/spacefm/spacefm.conf, or create it if needed, adding the following line:

    tmp_dir=/tmp/spacefm-temp

Finally, add the following line to /etc/sandfox/default.profile:

    hide=/tmp/spacefm-temp

Now close and recreate all your Sandfox sandboxes, or reboot. All access to SpaceFM sockets will be prevented inside sandboxes.

Examples

This section contains many examples to demonstrate Sandfox usage. You won’t necessarily do all of these in the order presented. When root is required, sudo is shown, but it is always okay to run Sandfox as root even when not required – programs will always be run as user (unless “––user root” is explicitly included, which is not recommended).

# Create a sandbox if none are open and run Firefox sudo sandfox firefox # Create a Firefox sandbox but don't start Firefox sudo sandfox --profile=firefox # Create a dual-use sandbox for both Firefox and Google-Earth, and start them sudo sandfox --profile=firefox --profile=google-earth sandfox firefox sandfox google-earth # Create a sandbox using a "myprogram" profile you have created sudo sandfox --profile=myprogram # Create a sandbox using a "myprogram" profile you have created # and run myprogram sudo sandfox myprogram # Create a sandbox using a "myprogram" profile you have created # and also load the firefox profile, and run myprogram sudo sandfox --profile=firefox myprogram # Add an additional bind to an existing sandbox named "firefox" # (or create one if it doesn't exist) sudo sandfox --sandbox=firefox --bind /user/data # Force update of the firefox sandbox after editing its profile # to add new binds. (missing binds will be added, but existing # binds will NOT be removed) sudo sandfox --sandbox=firefox --make # Manually create a sandbox without using a profile (although # the default profile is always loaded in addition to the binds # listed) sudo sandfox --bindro=/bin --bindro=/lib --bindro=/etc \ --bind=/tmp --copy=/home/myuser/.bashrc # Show the name and status of all open sandboxes sandfox --status # Run ls in shell mode to see the output sudo sandfox --shell ls / # Redirect output of a command to a file (quotes required) sandfox "ls / > /tmp/ls-output.txt" # Start an additional program in an available sandbox as a normal user # (This can also be done as a command from an icon or keyboard shortcut) sandfox firefox # Start a command with a quoted argument # (equivalent to myprogram "name with spaces") sandfox myprogram \"name with spaces\" # Start an additional program in a specific sandbox sandfox --sandbox=firefox firefox # Close a specific sandbox (close all windows running in it first) sudo sandfox --close=firefox # Close all sandboxes (close all programs first) sudo sandfox --closeall

Example session:

myuser:/$ ls / total 102 drwxr-xr-x 24 root root 4096 Dec 12 10:22 . drwxr-xr-x 24 root root 4096 Dec 12 10:22 .. drwxr-xr-x 2 root root 4096 Feb 1 09:34 bin drwxr-xr-x 3 root root 4096 Jan 22 10:21 boot drwxr-xr-x 17 root root 6080 Feb 1 14:08 dev drwxr-xr-x 62 root root 4096 Feb 2 09:59 etc drwxr-xr-x 4 root root 4096 Feb 1 17:19 home drwxr-xr-x 8 root root 4096 Feb 1 13:45 lib drwxr-xr-x 2 root root 4096 Dec 12 00:09 lib64 drwx------ 2 root root 16384 Nov 16 10:41 lost+found drwxr-xr-x 6 root root 4096 Jan 22 08:52 media drwxr-xr-x 12 root root 4096 Feb 1 16:41 mnt drwxr-xr-x 6 root root 4096 Jan 26 18:58 opt dr-xr-xr-x 168 root root 0 Feb 1 06:47 proc drwx------ 11 root root 4096 Jan 22 13:48 root drwxr-xr-x 2 root root 4096 Jan 24 22:38 sbin drwxr-xr-x 5 root root 4096 Jan 22 08:52 srv drwxr-xr-x 13 root root 0 Feb 1 06:47 sys drwxrwxrwt 13 root root 380 Feb 2 08:53 tmp drwxr-xr-x 11 root root 4096 Jan 22 10:21 usr drwxr-xr-x 14 root root 4096 Jan 28 09:38 var myuser:/$ sudo sandfox bash Loading profile "default" Loading profile "bash" Creating new sandbox "bash" >>> shell - you are myuser in sandbox "bash" <<< myuser:/$ ls / total 36 drwxr-xr-x 10 root root 4096 Feb 2 09:59 . drwxr-xr-x 10 root root 4096 Feb 2 09:59 .. drwxr-xr-x 2 root root 4096 Feb 1 09:34 bin drwxr-xr-x 3 root root 4096 Feb 2 09:59 dev drwxr-xr-x 62 root root 4096 Feb 2 09:59 etc drwxr-xr-x 3 root root 4096 Feb 2 09:59 home drwxr-xr-x 8 root root 4096 Feb 1 13:45 lib drwxr-xr-x 2 root root 4096 Feb 1 00:09 lib64 drwxrwxrwt 13 root root 380 Feb 2 08:53 tmp drwxr-xr-x 11 root root 4096 Jan 25 10:21 usr myuser:/$ ls /dev total 8 drwxr-xr-x 3 root root 4096 Feb 2 09:59 . drwxr-xr-x 10 root root 4096 Feb 2 09:59 .. crw-rw-rw- 1 root root 1, 3 Sep 7 00:15 null drwxrwxrwt 6 root root 120 Feb 1 14:24 shm crw-rw-rw- 1 root root 1, 9 Feb 1 13:47 urandom crw-rw-rw- 1 root root 1, 5 Sep 17 00:15 zero myuser:/$ exit exit <<< exit - you are myuser out of the sandbox >>> myuser:/$ _

How It Works

The Sandfox program is written entirely in bash, itself a well-tested core Linux component. You can open the sandfox script in any text editor to examine its commands or to make careful modifications. Sandfox uses only core Linux programs such as mount and chroot to create sandboxes. Rather than attempting to recreate the security these hardened programs provide, Sandfox simply inherits those qualities. Sandfox does nothing you can’t do directly in a console using mount, chroot, and similar commands. It simply automates the process and helps you organize and use sandboxes easily. Sandfox is a 1300-line program which does extensive error- and safety-checking and provides detailed feedback.

One way to learn more about how Sandfox works is to use the ––verbose option. Although the output is a bit messy, it will show you the exact commands as they are being issued.

In creating a sandbox, Sandfox creates a folder in /mnt/sandfox/SANDBOXNAME, which is used as the false root folder of a chroot jail. Then, using bind-mounts and tmpfs mounts, it adds folders and files to this false root.

Once the false root folder has been created, Sandfox starts a normal-user daemon version of itself in a chroot jail. This Sandfox daemon runs with your normal user privileges in the root-enforced chroot jail, which is a highly secure environment. See below for what this daemon does.

If you include a command on the command line when creating a sandbox, Sandfox will also start the command (such as firefox) in a chroot jail as a normal user. If you later run Sandfox as root to start additional programs, it will start additional chroot jails for these programs.

However, it is more convenient to be able to start programs as a user. This allows you to have clickable icons and keyboard shortcuts for starting your programs, without the need of entering the root password every time. This is where the Sandfox daemon comes in.

The Sandfox daemon runs as a normal user in the chroot jail – one instance for each sandbox you create. Using the inotifywait program, it efficiently monitors the folder /tmp/sandfox-events/SANDBOXNAME for changes. Anytime an executable file in that folder is modified or added, it will execute the file, then delete it. The daemon will run any file that is owned by its own user and is executable, and will also execute .desktop files. Links are not followed. This folder works similarly to KDE’s Autostart folder, which executes all the files in Autostart on login, except in this case they are executed as soon as they are placed there. The file that the daemon runs (generally a script to run your program) will inherit the daemon’s privileges – namely it will run as a normal user in the chroot jail.

When you run Sandfox as a normal user to start a program in a sandbox (eg “sandfox firefox” without sudo), Sandfox composes a script which will run the program, and drops it into the daemon’s event folder, where it will be detected and executed by the daemon running inside the chroot jail. This provides a mechanism for running additional programs without root. The script will also pass the current environment variables of the caller to the program called.

When closing a sandbox, Sandfox checks for existing mounts and attempts to umount all the mounts in the reverse order.

Installation Instructions

Follow the standard Script Installation Instructions. Alternatively, for Debian and Ubuntu a deb package and a PPA repository are available. On Arch Linux, sandfox can be installed automatically using the AUR.

Before running sandfox, install required packages using your package manager. For example, on Debian/Ubuntu:

apt-get install inotify-tools lsof

If you use SpaceFM, see Securing SpaceFM.

Related Forum Threads:

• CrunchBang: Securing Applications with Sandfox
• Arch Linux: Sandfox – A Poor Man’s Firefox Sandboxer
• Arch Linux: Sandboxing Options

Startup Scripts – Create A Sandbox At Boot

It is possible to automatically open a sandbox during boot, and automatically close all sandboxes on shutdown. In this way you can start programs in the sandbox(es) as a normal user without ever having to enter the root password. When starting Sandfox during boot, you generally MUST specify the “––user USERNAME” option to tell Sandfox what user will be using the sandbox.

Example startup scripts and installation instructions are shown below for Arch Linux and Ubuntu. A CrunchBang HowTo is also available.

Arch Linux
Create a new text file named “/etc/rc.d/sandfox” (sudo nano /etc/rc.d/sandfox) and paste the following text into it:

#!/bin/bash # Sandfox boot startup script for Arch Linux sandfoxuser=myuser sandfoxprofile=firefox sandfoxbin=sandfox . /etc/rc.conf . /etc/rc.d/functions start() { stat_busy "Starting Sandfox" $sandfoxbin --profile $sandfoxprofile --user $sandfoxuser if [ $? -gt 0 ]; then stat_fail else add_daemon sandfox stat_done fi } stop() { stat_busy "Stopping Sandfox" $sandfoxbin --closeall --user $sandfoxuser if [ $? -gt 0 ]; then stat_fail else rm_daemon sandfox stat_done fi } case "$1" in start) start ;; stop) stop ;; restart) stop sleep 3 start ;; *) echo "Usage: $0 {start|stop|restart}" esac exit 0

Edit the values of the sandfoxuser, sandfoxprofile, and sandfoxbin variables at the top. sandfoxuser is the normal user who will be running programs in the sandbox, sandfoxprofile is the profile name from /etc/sandfox to create the sandbox, and sandfoxbin is the location of the sandfox script on your system. Feel free to customize the above startup script with additional profiles or have it run sandfox multiple times to create multiple sandboxes.

Next, execute the following commands:

# Make startup script executable sudo chmod +x /etc/rc.d/sandfox # Add sandfox to DAEMONS array in rc.conf sudo sed -i 's/^\(DAEMONS=.*\))/\1 sandfox)/' /etc/rc.conf

(Alternatively, you can use the /etc/rc.local and /etc/rc.local.shutdown scripts on Arch Linux to open and close sandboxes.)

A Potential Problem: Some Arch users have encountered a problem due to the lack of a ~/.Xauthority file in their sandbox user’s home folder at boot time, as described here. To remedy this you may need to change this line in the script:

$sandfoxbin --profile $sandfoxprofile --user $sandfoxuser

to something like:

( while [ ! -e /home/$sandfoxuser/.Xauthority ]; do sleep 1; done; \ $sandfoxbin --profile $sandfoxprofile --user $sandfoxuser ) &

 

Ubuntu And Similar
Create a new text file named “/etc/init.d/sandfox” (sudo nano /etc/init.d/sandfox) and paste the following text into it:

#!/bin/bash # Sandfox boot startup script for Ubuntu and similar sandfoxuser=myuser sandfoxprofile=firefox sandfoxbin=sandfox start() { echo -n "Starting Sandfox: " $sandfoxbin --profile $sandfoxprofile --sandbox $sandfoxprofile --user $sandfoxuser if [ $? -gt 0 ]; then echo "failure" RETVAL=$? else echo "success" RETVAL=0 fi } stop() { echo -n "Stopping Sandfox: " $sandfoxbin --closeall --user $sandfoxuser if [ $? -gt 0 ]; then echo "failure" RETVAL=$? else echo "success" RETVAL=0 fi } case "$1" in start) start ;; stop) stop ;; restart) stop sleep 3 start ;; *) echo "Usage: $0 {start|stop|restart}" RETVAL=1 esac exit $RETVAL

Edit the values of the sandfoxuser, sandfoxprofile, and sandfoxbin variables at the top. sandfoxuser is the normal user who will be running programs in the sandbox, sandfoxprofile is the profile name from /etc/sandfox to create the sandbox, and sandfoxbin is the location of the sandfox script on your system.

Next, execute the following commands:

# Make startup script executable sudo chmod +x /etc/init.d/sandfox # Add sandfox to runlevels sudo update-rc.d sandfox defaults

If you decide you DON’T want Sandfox to start at boot, you can cancel the startup script with:

# Remove from runlevels sudo update-rc.d -f sandfox remove

Feel free to customize the above startup script with additional profiles or have it run sandfox multiple times to create multiple sandboxes.