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 are created in the Sandbox folder according to the following hierarchy:
. . drive
. . . C
. . . D
. . . Q
. . user
. . . all
. . . current
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 the FileRootPath setting is omitted, the BoxRootFolder setting is used instead. The Box Root Folder setting specifies a path to a group of sandboxes. In other words, if Box Root Folder specifies the folder C:\MySandbox, then the sub-folders drive and user are created as C:\MySandbox\Sandbox\DefaultBox\drive and C:\MySandbox\Sandbox\DefaultBox\user, respectively, and assuming the sandbox is called DefaultBox. Please note that BoxRootFolder is a deprecated setting.
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.
Files that are created or modified in or below profile (or home) folders, such as C:\Users\joe (on Windows Vista and later) are redirected into the sandboxed user\current folder.
Files that are created or modified in or below the generic (or All Users) profile, are redirected into the sandboxed user\all folder.
Other files that don't match either of the above paths are redirected to the sandboxed drive\X folder, where X would be the drive in which the files were supposed to have been written.
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.
Note that the Sandbox folder itself resides on one particular drive, so even as sandboxed programs may create and modify files in multiple drives, all these files will end up residing physically in the same drive -- the drive where the Sandbox folder resides.
Apart from the two sub-folders, drive and user, the Sandbox folder itself contains the file RegHive, and typically also RegHive.LOG. These hold the sandboxed registry. See below.
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.
Sandboxie creates the hive file in the Sandbox folder, as the files RegHive and RegHive.LOG. This hive is mounted (or in other words, loaded into the registry) when a sandboxed program starts. The hive is unmounted when all sandboxed programs end.
The sandboxed hive has the following position and structure within the global structure of the Windows registry.
. . KeyRootPath
. . . machine
. . . user
. . . . current
The KeyRootPath setting specifies a path to the root of a particular sandbox. If omitted, it defaults to _HKEYUSERS\Sandbox(user name)(sandbox name). For example, if the user joe is using the sandbox DefaultBox, the default KeyRootPath is _HKEY_USERS\Sandbox_joeDefaultBox.
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_LOCALMACHINE\Software\NewKey, it will be redirected to create instead (KeyRootPath)\machine\Software\NewKey.
If the sandboxed program was trying to create the key _HKEY_CURRENTUSER\Software\NewKey, it will be redirected to create (KeyRootPath)\user\current\Software\NewKey.
With the sandboxed registry, the rules for redirection are simpler than for sandboxed files:
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.
A registry key created or modified below the HKEY_CLASSES_ROOT tree will be redirected below the sandboxed _user\currentclasses key.
Note that the sandboxed user\current\software\classes key is a symbolic link to the _user\currentclasses key which means and the keys are effectively synonyms and share the same content in the sandboxed Windows registry.
As with files, access to a key which has a copy in the sandboxed registry will be redirected to use the copy in the sandbox. Read-only access to a key which does not have a copy in the sandboxed registry will be permitted to access the key outside the sandbox. This behavior can be affected with the registry-related settings OpenKeyPath, ReadKeyPath, and ClosedKeyPath.
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.
. . 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\Session0.
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.