Sandboxie review – Application isolation for experts
Updated: September 14, 2019
The last time I tested system sandboxing software was in the XP era. I remember programs like
ShadowGuard, if my memory servers me well, and Deep Freeze, designed to create a virtual filesystem
layer to which changes would be made during your active session, and then on next reboot, these would
be scrubbed back to a clean state. In essence, a read-only system with the ability for selective
modification.
For applications, you may have wanted something less complicated – and for those in need, there was
Sandboxie. As it happens, I never really got to try the
application, not in its early days nor later after it was acquired, but now, having tried
Windows Defender Application Guard (unsuccessfully) on
Windows 10 Home, I decided to give this program another look. So let’s have a test and review of
Sandboxie. Let’s build us a security castle!
Setup and configuration
The installation wasn’t complicated, but it does require that you pay attention to what you’re
doing. The principal part of the setup is the Sandboxie driver, which does all the magic in the
background. I had no problem getting this done on a Windows 10 Home box – not using any other security
software except the built-in Mitigation Protections.
On first run, Sandboxie scanned the software on my system and asked me whether to apply various
configuration settings. I’m not sure what this does at this point, but I let the step complete. Well,
it’s not like you have the option to not click OK, but you can remove the entries shown.
Tutorial
Because Sandboxie usage isn’t trivial, the program starts with a tutorial. You are asked to follow a
few steps, so you get familiar with how the application works. I found the wizard somewhat clunky, and
I only figured what gives after I completed it, so to speak. TL;DR, you will have a Sandboxie-ed
shortcut for your default Web browser on the desktop, and if you run that, your browser (Firefox in
this case) will launch sandboxed. The main program interface is a task manager of a sort, and it will
show you all your sandboxed applications, grouped by their containers (you can later configure
different sandboxes). When a program is running under Sandboxie, you can identify it by the [#] prefix
and suffix in the title (not trivial as not all programs show titles), and by a yellow border when you
hover the mouse over the application window.
Playing in the sand
I started using the program, and soon learned that it has a function called Immediate Recovery. If
you copy a file into one of the pre-defined folders, you can “recover” them from the sandbox and into
your real system. By default, Sandboxie isolates applications running inside it from the outside
filesystem, so if you close them, all changes will be lost (like say downloads). It’s like running a
browser in a Linux live session, where you have no persistence, and the changes are gone if you reboot.
If you don’t know what Linux is, ignore the last sentence.
Close means you simply keep the file inside the sandboxed session; not very
intuitive.
By default, you will have a shortcut for your default browser, but you can launch any program via
right-click. You will then have the option to select the desired (sand)box.
The program behaved well. For example, I couldn’t see the browsing history or bookmarks in either
Firefox or Chrome while running sandboxed, and I didn’t notice any performance degradation or conflict
with plugins or extensions or media playback. But in Chrome, you have no title, so no indication you’re
running sandboxed unless you hover the mouse cursor.
Settings and more settings
I soon found out that there are multiple ways to tweak the Sandboxie configuration. If you
right-click on a process listed inside the sandbox, you can make some changes to how it behaves. But
this is only effective for your current session. Then, you also have global settings. This is somewhat
confusing.
It was a little hard finding the per-sandbox global settings, but find them I did. Then, you have a
super-long list of options you can tweak, including the look and feel, how and if you recover or delete
files, grouping of programs (like browsers based on Firefox or Chromium), and migration of files into
the sandbox. I found some of the options quite tricky, because the explanations use the not format. So
you need to put your brain in reverse to understand what will actually happen.
Next, you have a long, detailed list of restrictions and access rights. You can decide what type of
resources the sandboxes applications will have (for that particular box). You can use a very fine-tuned
list of permissions, including which files can be read or written to, which files will not be
accessible, network ports, and more. Again, using the Linux analogy, this is similar to writing
AppArmor or SELinux rules, and it’s no trivial task. You really need good understanding of the system
internals to be able to make changes here without compromising your security or breaking your
applications – or even your system. Yes, if you’re not careful, you can lock yourself out of Windows.
For instance, the listed DLLs below – what do they mean to an ordinary user?
Things become even more complicated when you start looking at Registry, IPC, or COM. This is true
nerdy territory, and unless you fully understand what a typical Windows process memory mapping is, then
you shouldn’t even be looking at this section.
The Applications option opens into a super-long list of categories, with various default rules that
you can add or remove. You can configure browsers, email readers, PDF software, and many other
applications and tools separately. Again, I found lots of the rules/explanations to be difficult to
understand. For instance, if a rule is written, but it has no sign, does that mean it’s blocked? Or
just a rule you can configure? Or Default exclusions for Immediate Recovery. What does that mean? File
types or locations that will be recovered? Or they will be excluded?
You also have the option to edit the program configuration through an ini file, which feels a bit
old school, but it’s there, for those in need of speed and geeky actions. All in all, the configuration
piece leaves a lot to be desired, and it also emphasized how complex it is.
How does this compare to other methods?
Well, I’m asking the same question I asked in the App Guard article. If you’re using browsers that
already have sandboxing capabilities, if you’re using
Exploit Protection, if you’re using the
extension like
Noscript, and also possibly running under a standard
(limited) account, how much value is there to something like this?
The first thing that comes to mind – arbitrary execution of code, but then all of the above
definitely limit the applicability of that. The second thing, and a far more important one, is: where
does the sandbox model break? And the answer to that is, the user. Indeed, in the testing, I noticed
that you have the option to save files to your unsandboxed folders, and therein lies the problem. If
you allow a bad file through, then you will eventually use it in an unrestricted manner. Perhaps it
won’t render any damage in the isolated session, but it will later on, especially if you don’t notice
the “bad” symptoms and become convinced it is safe. In fact, the presence of a powerful security tool
may even lower your sense of self-preservation.
Then, you also have the option to tinker with sandbox settings and make changes – add or remove file
and registry access, define folders for immediate recovery, and similar. If you’re not deeply skilled,
you could potentially create a gap in your sandbox. This becomes even more apparent if you actually
have a usability problem (as a result of security restrictions) and then try to work around it. Now,
this is not a Sandboxie issue, but a general one. It’s a paradox of software security. If you’re not
skilled enough to use the software to its full potential, you’re not likely to benefit from it, but if
you are, then you most likely don’t need it.
This is why I find EMET or Exploit Guard extremely valuable. They may cripple your usage in some
cases as a results of applied mitigations (very rare but
possible), but this will be done without classifying
software as good or bad. Instead, this is done on a much lower level – good or bad instruction or
memory access. Exploit Guard does not discriminate between bad software and good software written
badly.
Similarly, if you use a standard account, you’re limited in what you can do. And this has nothing to
do with a random hax0r trying to pwn you or anything like that. This is much more rudimentary than
that. You have no privilege changing many of the system settings. Period. It doesn’t matter if it’s
deliberate or by mistake or whatever. It’s not possible.
Back to Sandboxie. By default, it does a lot of good stuff, and if you don’t tinker, you should have
a reasonable layer of extra security. But then, Sandboxie does not limit what happens within the
sandbox and it will not prevent code from running or prevent you from copying data out of the sandbox.
Moreover, you have the ability to tinker and change settings, which could potentially open holes in the
isolation mechanism. From what I was able to test, Sandboxie is good in isolating Internet-facing
programs from the system, but it will not limit access to Internet data, like your browsing
activity.
Conclusion
Sandboxie is a nice, robust program. It offers advanced users a high degree of flexibility in
setting up low-privilege containers for untrusted and Internet-facing software. You can isolate
these applications, in a manner that is somewhat similar to how mobile operating systems work. Except
Sandboxie did this ages ago. Furthermore, if you don’t like how the isolation mechanism is working, or
one of the programs isn’t behaving or functioning correctly, you can easily execute it outside the
Sandboxie context, and Bob’s your uncle.
However, Sandboxie also has limitations. The setup and configuration are far from trivial, and
require a solid level of understanding of system, devices, access, and alike. This can turn Sandboxie
usage into a burden. Lastly, Sandboxie limits privileges but it does not sanitize them, which means if
there’s a memory leak within the context of the running application (i.e. illegal instruction of some
kind), Sandboxie will not stop that. Or prevent you from copying a file you downloaded from the Web out
of the container. Which means Sandboxie makes sense when you
don’t trust what you’re doing rather than when you do. I believe its
value is in testing applications and if you need to roam the wild Internet unchecked. All in all,
recommended and worth checking. Perhaps future versions will have a simplified interface and a more
intuitive access control flow. Take care.