Configuring SBIE to balance isolation-by-default, security, and compatibility [suggestions welcome!]

[e-t-l]

The Objective

1. Develop a simple tutorial for new users to configure Sandboxie-Plus (Free tier, ideally) for common use-case "scenarios."
2. The tutorial will synthesize information from various Discussions, Issues, and other documentation.
3. Eventually, this tutorial may be used wholly or in part to update and modernize and flesh out the Getting Started documentation, which IMO is a little bare-bones.
4. Depending on the complexity of the steps involved in configuring SBIE, I may end up writing some batch scripts or even a lightweight Windows service to help users set up common sandbox scenarios.

Scenario: Hardening Windows with SBIE isolation-by-default

One particular use-case that has the potential for broad appeal is using Sandboxie not just to virtualize individual cases of potential malware, but as a "daily driver" Windows hardening technique, reducing attack surfaces by isolating new programs from the system as a default.

This setup would be intended for use on a fresh Windows install, where we can assume a clean device. Some steps will likely include:

• ForceProcess rules to isolate 3rd-party programs and installations by default
  • Breakout* rules to avoid isolating basic Windows system processes and executables
  • ForceProcess exceptions to ensure isolation of potentially-dangerous Windows processes (e.g. Explorer.exe) that are called by 3rd-party programs
• Multiple sandbox configurations for different categories of program, such as...
  • Safe to install normally, but always run sandboxed (shared)
  • Install sandboxed and run sandboxed (shared)
  • Install/run sandboxed in its own sandbox (unique)
  • The above sandbox types, with variations of:
    • Keeping/destroying contents upon exit
    • Prompting Immediate Recovery of files
    • OpenFilePath for common and/or user-specified locations
• .ini adjustments to maximize compatibility and stability, so that after initial setup it can run with relatively little user input. (Users should not need much technical understanding of Sandboxie to use this effectively.)
• Running ProcMon to log all Registry changes for different sandboxes
  • Ideally, users will also have an easy way to recover Registry changes that are deemed benign
• Guidance on how to maximize compatibility with a 3rd-party antivirus program the user may wish to have installed

Users will have a simple dialog to choose whether to isolate new programs.

(This is where batch scripting or a dedicated Windows service might be useful, if it can't be accomplished just within SBIE.)

• When the user runs a new program, they will be immediately prompted to choose whether to run it unsandboxed, in a shared sandbox, in a unique sandbox, etc. There will be an option to remember this choice for future runs of that program.
• If the program is an installer, the user will be similarly prompted whether to install the program in a sandbox, what type of sandbox, whether to remember that decision, etc.
• For unsandboxed installations, there will be an option to allow those files created during installation (e.g. Program Files, Appdata, .exe and .dll files, etc.) to run unsandboxed by default.

The End Result

After initially installing and configuring Sandboxie, the user will have a Qubes-like (or rather, Qubes-lite) hardened Windows environment using tiered levels of virtualization, depending on the level of trust:

1. Fully trusted Windows system processes can run unvirtualized and unimpeded ("dom0", if you will). Highly trusted 3rd-party programs that require deep system integration (e.g. antivirus, firewall, VPN) can also be set to run unvirtualized alongside the system.
2. Highly trusted 3rd-party programs with significant inter-program communication and/or file creation (e.g. MS Office, Adobe CC) can be installed on the real drive and run in one or more shared, persistent, sandboxes with relaxed isolation rules, like broad OpenFilePath permissions
3. Reasonably trustworthy programs that do not significantly interact with other programs or files can be installed/run in shared sandboxes with Immediate/Quick Recovery.
4. Untrusted programs can be installed/run in unique sandboxes.
5. Malicious programs can be installed/run in unique sandboxes that are destroyed upon termination.

The tutorial to set up this configuration will be understandable enough that users can choose only certain aspects of it to implement. For example, a user who wants the convenience of these preconfigured sandbox tiers but does not want isolation-by-default can either manually (or perhaps with a simple batch script) remove the ForceProcess parameters, so that new programs are not constantly prompting isolation dialogs.

Ultimately, it will be a thorough—but not highly technical—setup guide that will leave new users with ready-to-use, easy-to-understand sandbox templates that require minimal further configuration to start using without breakage.

[e-t-l]

I will admit that I myself am still learning the ins and outs of Sandboxie. There are many of you in the community with deeper technical understanding of Sandboxie (as well as the things that sandboxing actually involves like debugging, trace logs, API calls, system hooks, etc.), and I welcome your thoughts and input! If there are any steps that I described that made you think, "Ah, I know how that should be implemented!" please contribute an explanation! If there are steps that made you think, "Wait, that will never work," (and I'm sure there are!) I would greatly appreciate your insight. And of course if there's anything I've forgotten, or any glaring holes in this plan, please don't hesitate to share.

As I continue to familiarize myself with the technical implications of different SBIE options, one big question I have is: Does this seem doable with SBIE Free, or would this necessitate paid features like Security Hardening and/or Compartment mode? (I'm still trying to formulate a decent layperson's description of what those modes change in practice.)