Skip to content

Sandbox Hierarchy

Overview

When sandboxed programs create (or modify) objects, such as files, in fact, some kind of data should be created. Sandboxie creates these objects out of the way, to protect the system from harmful changes. But these objects must reside somewhere in the system. This page describes where various types of sandboxed objects are placed.

Beginning with version 2.80 of Sandboxie, the layout of the sandbox is not tied to computer-specific device names and account names. See Portable Sandbox for more information.

Files

With the default file-layout options, redirected files are organized beneath FileRootPath approximately as follows: 

  . FileRootPath
  . . drive
  . . . C
  . . . D
  . . . Q
  . . user
  . . . all
  . . . current
  . . . public
  . . share
  . . . server
  . . . . share
  . RegHive

The user\public branch applies where a Public profile is available. SeparateUserFolders and the volume-layout options can change these folder names; see Sandbox Roots and Volume Layout.

The FileRootPath setting specifies a path to the root of a particular sandbox. In other words, if FileRootPath specifies the folder C:\MySandbox, then the sub-folders drive and user are created as C:\MySandbox\drive and C:\MySandbox\user, respectively.

If no effective FileRootPath is available, the deprecated BoxRootFolder is used if present. It supplies a base folder: for a box named DefaultBox and BoxRootFolder=C:\MySandbox, the derived file root is C:\MySandbox\Sandbox\DefaultBox, with drive and, under the default profile layout, user beneath it. If neither setting is available, Sandboxie uses its built-in file-root default.

As sandboxed programs create new files or modify existing files, Sandboxie redirects these operations to act on paths that lead into the sandbox. If the sandboxed program was trying to create the file C:\NEW.TXT, it will be redirected to create instead (FileRootPath)\drive\C\NEW.TXT.

If the sandboxed program was trying to create the file C:\Users\joe\Documents\NEW.TXT, it will be redirected to create (FileRootPath)\user\current\Documents\NEW.TXT.

With SeparateUserFolders=y (the default), files created or modified in or below the current user's profile (or home) folder, such as C:\Users\joe (on Windows Vista and later), are redirected into the sandboxed user\current folder.

Under that same option, files in the generic (or All Users) profile use user\all; a recognized Public profile can use user\public. With SeparateUserFolders=n, ordinary local profile paths instead follow the drive layout, such as drive\C\Users\joe. Existing content is not moved between these layouts automatically.

Other local files normally use the sandboxed drive\X folder, where X is the drive letter for their host volume. With UseVolumeSerialNumbers=y and a readable filesystem volume serial, the component becomes, for example, drive\C~1234-ABCD. For volumes mounted without a drive letter, the default mapping follows a mounted directory; UseVolumeGuidWhenNoLetter=y can instead use drive{volume-guid}.

Files that are created or modified on a remote network share are redirected into the sandboxed share\servername\sharename folder.

When a program tries to open a file for which a copy already exists in the sandbox, Sandboxie will redirect the program to the copy of the file that was previously stored in the sandbox. On the other hand, if a copy for the file does not exist in the sandbox, and if the program does not try to modify the file, then Sandboxie will permit read-only access on the original file outside the sandbox. This behavior can be affected with the file-related settings OpenFilePath, ReadFilePath, and ClosedFilePath.

For an ordinary directory-backed box, the file root resides on one storage volume. Sandboxed programs may create or modify files that appear to be on several host drives, while their redirected copies are stored beneath that box's file root.

Alongside the file-layout folders, the sandbox root contains RegHive and may contain associated registry-hive log files. These hold the sandboxed registry. See below.

Registry

Registry keys are created in a sandboxed registry hive. A registry hive is the Microsoft Windows term for a group of related registry keys that are stored in a single hive file.

The hive's backing file is RegHive beneath FileRootPath; Windows-maintained supporting hive files may also exist. The hive is mounted (loaded into the registry) during sandboxed process initialization. Multiple processes can share the mount, and unload is coordinated when the hive becomes eligible; it may not be immediate after all sandboxed programs end.

With the default registry root, the sandboxed hive has the following position and structure within the global structure of the Windows registry. 

 . HKEY_USERS
 . . KeyRootPath
 . . . machine
 . . . user
 . . . . current

The KeyRootPath setting specifies the registry location where the hive is mounted, not its backing filename. If no effective value is configured, it defaults to HKEY_USERS\Sandbox(user name)(sandbox name). For example, if the user joe is using the sandbox DefaultBox, the default KeyRootPath is HKEY_USERS\Sandbox_joe_DefaultBox.

As sandboxed programs create new registry keys or modify existing keys, Sandboxie redirects these operations to act on paths that lead into the sandbox. If the sandboxed program was trying to create the key HKEY_LOCAL_MACHINE\Software\NewKey, it will be redirected to create instead (KeyRootPath)\machine\Software\NewKey.

If the sandboxed program was trying to create the key HKEY_CURRENT_USER\Software\NewKey, it will be redirected to create (KeyRootPath)\user\current\Software\NewKey.

For normal registry virtualization, the main mappings are:

  • A registry key created or modified below the HKEY_LOCAL_MACHINE tree will be redirected below the sandboxed machine key.

  • A registry key created or modified below the HKEY_CURRENT_USER tree will be redirected below the sandboxed user\current key.

  • HKEY_CLASSES_ROOT is Windows' Classes view, not one independent uniform Sandboxie root. Its machine/per-user merge and Sandboxie's sandbox-side Classes mapping are separate relationships.

Sandbox customization can create a symbolic link from user\current\software\classes to user\current_classes. Where that link is created, the two names refer to the same sandbox-side content.

A normal read-only open of an existing host-only key can use the host key without first creating a sandbox counterpart. When sandbox state exists, selected key/value queries and enumeration can merge it with eligible host state; a sandbox key is not necessarily a complete copy that fully shadows the host key. This behavior can be affected with the registry-related settings OpenKeyPath, ReadKeyPath, and ClosedKeyPath. See Registry Virtualization for the merge, deletion, access-mode, and lifecycle boundaries.

Inter-Process Objects

These objects are used by programs to share information, synchronize processing, and provide services. These objects are never written to disk and they disappear when the system shuts down.

Sandboxie isolates these objects in order to make it possible to run the same program sandboxed and un-sandboxed side-by-side. It also keeps sandboxed programs from interfering with un-sandboxed ones.

These objects are created in the NT object namespace. Their position and structure within that namespace are as follows. 

 . IpcRootPath
 . . BaseNamedObjects
 . . . Global
 . . . Local
 . . . Session
 . . RPC Control

The IpcRootPath setting specifies a path to the root of a particular sandbox. If omitted, it defaults to \Sandbox(user name)(sandbox name)\Session(session number). For example, if the user joe is running in session zero, and using the sandbox DefaultBox, the default IpcRootPath is \Sandbox\joe\DefaultBox\Session_0_.

Below the IpcRootPath, there are object directories which comprise the NT namespace, and match the layout of existing object directories outside the sandbox area. The directories are created with a persistent attribute, which means they will only disappear at system shutdown.

Objects created by sandboxed programs are created within the sandbox object directories. If the program is running outside the supervision of Sandboxie, it would typically create such objects in the \BaseNamedObjects object directory.

Note that objects may be created without a name, in which case the object is effectively isolated to the particular program which created it. However, a program can access the internals of another program in order to locate and use such nameless objects. To mitigate this, Sandboxie prevents a program in the sandbox from accessing a program outside the sandbox in this way.

The free utility WinObj by Sysinternals (now a part of Microsoft) can be used to display the NT object namespace.

Unlike the case with files or registry keys, sandboxed programs are never permitted to access IPC objects outside the sandbox namespace, not even for read-only access. This behavior can be affected with the registry-related settings OpenIpcPath and ClosedIpcPath.

Note that Sandboxie includes a number of built-in OpenIpcPath settings to allow programs to function correctly, and in a typical system, more OpenIpcPath settings are applied through compatibility settings for third-party software.