SandboxieReflector was created by Carl Colijn, TwoLogs, primarily to scratch my own itch. It is a user-contributed utility for use with the excellent Windows security application Sandboxie; check it out if you haven't already! It is available free of charge; you can download the installation zip file from the links below;
SandboxieReflector could, in the hands of unknowledgeable persons, make your Sandboxie totally ineffective. Please only use this product if you know what you're doing and if you can assess the risks and are willing to accept them!
SandboxieReflector is a small application that lets you reflect some pre-specified commands (via a command line) into a designated sandbox, even from inside another sandbox. This can be most useful if certain actions inside one sandbox must be executed inside another one. Concrete examples of this are e.g.:
To pass commands out of a sandbox, SandboxieReflector is made of two cooperating applications - the "Reflector" and the "Effectuator". The Reflector is started inside of a sandbox, and needs to be given the command to execute via the command line. The Reflector then passes it's command line arguments via the pipe named "SandboxieReflectorCommands" unmodified to the Effectuator. The Effectuator examines the command line arguments given, links it to pre-defined profiles, and if all matches up it executes the correct command in the correct sandbox.
Since this kind of functionality could in essence be a giant breach in Sandboxie's security, the actual commands are specified in pre-defined profiles to keep the level of security as high as possible. These profiles must be specified by you in the settings file (which should be placed outside of the reach of any sandbox's influence, to keep bad actors out). With this set-up any malicious forces will only be able to run these pre-defined commands, and then only if they know the names you have given to the profiles as well.
Installation is simple - just reserve a folder for SandboxieReflector anywhere on your system, copy over all files found in this archive, and run the executables from there. SandboxieReflector doesn't modify any registry keys or files, so an uninstall is as simple as deleting it's folder.
The Effectuator needs to be running for Reflectors to be able to contact it. You can start the Effectuator by running it with the /s command line option; this will put it in the notification area. If you use SandboxieReflector regularly, consider creating a shortcut to it in your "Program Files\Startup" start menu with this switch in it.
Since the Reflector needs to be able to communicate with the Effectuator, you need to open up the used communication channel in any sandbox you want to use the Reflector in. This is done by adding the line
OpenPipePath=Reflector.exe,\Device\NamedPipe\SandboxieReflectorCommands
to that sandbox' configuration (or to the [GlobalSettings] section to enable it for all sandboxes).
The command line issued to a Reflector is passed on verbatim to the Effectuator. There are currently two types of commands supported (both not case sensitive);
For the Effectuator to run, you need to create the settings file first. This settings file should be named "SandboxieReflector.ini", and should be placed next to the "Effectuator.exe" file.
The SandboxieReflector.ini file is a regular Windows INI file. It should contain the following section:
[GlobalSettings] SandboxiePath=<Sandboxie's installation path>
The settings are:
Each execution profile section should be noted as follows:
[ExecProfile_<profile name>] Box=<sandbox name> UsesDDE=<y|n> CmdLine=<command line to run>
The settings are:
CmdLine=Notepad.exe $file$The $file$ above will be replaced by the values specified in a mandatory /p file <file path> on the Reflector's command line. Note that parameter names are not case sensitive. You can insert a "$" sign by doubling it, like $$. All values will be enclosed in double quotes for you, so you should not add the quotes yourself in this command line. If more than one value is specified, they will be seperated with a space. If the command is not to be run in any sandbox, the main executable's path should be fully specified.
Warning: reflecting DDE commands is a much tougher job than reflecting simple command lines. Be aware that setting this up correctly might prove a nice time sink if you're not sure what you're doing ;)
Each execute profile is represented by a command line. However, sometimes the command you want to reflect also uses DDE (Dynamic Data Exchange) to work properly. One such place DDE is sometimes used in conjunction with a command line is in file and protocol associations. This happens e.g. with .doc files registered by Word 2003, but e.g. FireFox also registers DDE commands with the "http(s)" protocol handlers. The below explanation describes how to enable DDE commands when sandboxes are involved. It takes Explorer's use of file associations as an example, though it should also be true for other uses like your e-mail client opening an URL in your browser via a protocol association. In fact, almost anything being started/opened through ShellExecute should be able to work.
When an application supports DDE for opening files, it can say so when registering it's file association in the registry by adding a "ddeexec" key. When Explorer is asked to open a file that is registered this way, it first broadcasts a DDE call to all applications to ask them to open it (assuming any responding app will in fact be the correct one). If no-one responds, then Explorer falls back on the regular command line to start the needed app, and when the app is started it makes a targeted DDE call to it to finalize the opening of the file. If any of the latter steps fails, Explorer raises an error that it cannot find the requested file, suggesting you have incorrectly spelled it's name (which of course is a misleading message in this situation).
Behind the scenes DDE calls are messages back and forth between the source and target windows. Thus, when either the source or target application is sandboxed, Sandboxie will rightfully block any message coming from the sandboxed application to protect the rest of the system. Step one is thus to open up this conversation channel via some OpenWinClass settings in Sandboxie.ini. For this you need to know the exact window class names of the windows involved; this can be found by using an application like WinSpy++ or by using Sandboxie's Resource Access Monitor and looking for any blocked window classes.
If you have opened up the correct windows, then Explorer should already be able to open a file of the involved type when the app is already running. When the application is not yet running though, Explorer will now start the Reflector in stead (since we reflected the command line), and then it expects the Reflector to handle the ensuing DDE conversation. By specifying the "UsesDDE" setting, the Reflector will pass on the DDE initialization calls straight to the just opened application, and from then on Explorer will talk to the correct application again. You therefore also have to open the window classes relevant for the DDE conversation for the Reflector.
Note that most applications have an option of opening files from the command line, without using DDE. If setting up the DDE communication doesn't work out for you, then you can most often simply modify the file association to only use a command line. Note however that this might have other side effects, like multiple instances of the app running, while the app isn't designed to allow this, so use this method at your own risk.
The main reason I created SandboxieReflector is to use it as a launchpad for file associations, where the applications are installed each in their own sandbox. When you install an app in it's own sandbox, and when the app registers some file associations, those associations are only going to be effective when you open an Explorer instance in that sandbox. But if you export the relevant file association portions of the registry, re-map the paths and commands to use SandboxieReflector, and then apply the reg file outside of the sandbox, any process (incl. within other sandboxes) can open that file type in the designated sandbox.
A simple step-by-step guide for this is:
By now you should be able to open document files for your new app in any sandbox you like, while the new app will always run in it's own sandbox!
Recent versions of Windows also introduced two alternative methods for apps to start when opening file associations - the DelegateExecute and DropTarget routes. These method route the executing through COM. Opening up the relevant COM ClsID's in Sandboxie might make it all work, but SandboxieReflector has no notion of these two methods.
Since I expect the audience for SandboxieReflector to be above average considering computer literacy, and since I want to somewhat discourage novice users from using this solution for their own good, I have decided to not develop/document it any further. Also, there are possibly plans to add forcing certain applications to run in certain sandboxes to the core Sandboxie functionality, making any further development of SandboxieReflector a dubious investment. I have thought about adding DDE proxying support to SandboxieReflector, but since this can be solved by white-listing window classes once Sandboxie supports running apps cross-sandboxed, I'll pass on that as well.
Therefore please do not send me support inquiries, unless they concern potential security breaches I have not noticed, or if you want to suggest some nice (and easy to add) additions. Also consider voicing your desire for this feature in Sandboxie itself to possibly make the addition come faster ;)
When I needed to re-install the entire OS again on both my dev PC's due to accumulated Win rot, I wanted to start using virtual machines as much as possible due to their benefits;
However, virtual machines come with some big disadvantages;
Ideally I also wanted to isolate each app in it's own virtual machine to make it easier in the future to throw one away and still keep the rest of my set-up clean and working. So when I then stumbled upon Sandboxie, I decided the best way to proceed for me would be to install each application in it's own sandbox and forget about virtual machines. If I stick with the current OS on all my machines, the effects would be:
Sandboxie however posed some (understandable) restrictions on this set-up, so I needed to circumvent them, resulting in SandboxieReflector.
Since this concept can for some people be a very useful addition to Sandboxie as well, I decided to slap on a better GUI, add this documentation and make it freely available.