Sandboxie Support

Use case:

1. Create a Parent Sandbox Sandbox-Parent and install a Web Browser inside it.
   Once the installation is finalized, in most cases the Parent Sandbox container should be made READ ONLY (but don't force it).
2. Create child sandbox Sandbox-Child1 with Sandbox-Parent as its parent.
   When reading files, registry, etc... it goes like this: Sandbox-Child1 -> Sandbox-Parent -> Real OS.
3. Run the Web Browser from Sandbox-Child1, do some tests like trying out a Browser Extension.
   Now I've finished testing, I reset sandbox to clean state by using [Delete Contents] command on Sandbox-Child1.
4. After that Sandbox-Child1 should contain nothing, but I can still run the Web Browser from it.
   As all the program files, registry entries, etc... of the Web Browser are stored inside Sandbox-Parent thus not affected by deleting the content of the child sandbox Sandbox-Child1.
5. Best part is, I can create multiple child sandboxes of one parent sandbox.
   (a browser for using online banking, another one for working, yet another one for entertainment with tons of extensions, etc...)

Currently there's no Parent-Child feature like that, of course I can install multiple copy of an software inside multiple sandboxes multiple times, but that's just suck a waste of time, waste of disk space, and every time I use "Delete Contents" command I'll have to install the software all over again.

Why not just install the Web Browser directly and create different sandboxes to run it with?
"Trust No Program" is the slogan of sandboxie, and that's why I don't install programs outside sandbox. Besides that, even if I fully trust the program I'm using, installing the program directly to OS has limitations. For example, it's hard to keep different versions of some program to co-exist, installing them to separate sandbox solves this problem. If I accidentally upgraded the program outside sandbox, it could break all the sandboxes.

I understood all you said above, I think. Except this phrase not clear enough to me:

RadarNyan wrote: ↑

Thu Dec 21, 2017 1:40 am

Why not just install the Web Browser directly ?

By directly, you mean to install it outside a sandbox directly to the real OS?

I actually do this very thing already with the majority of my sandboxed software.

By default my sandboxie folder (FileRootPath) points to my ramdisk, but I also have a folder called "PersistentSandbox" which houses permanent template sandboxes that other boxes pull from.
So for instance create 2 sandboxes, the first called "FirefoxPersistent" and the second called "Firefox". Change the FileRootPath of "FirefoxPersistent" to "C:\PersistentSandbox\Firefox", leave the "Firefox" sandbox defaulting to it's original location. Install firefox in the "FirefoxPersistent" sandbox and set it up exactly how you want it, then protect the sandbox from deletion in sandboxie options.

Once done create a batchfile like the following:
Create a shortcut to the batchfile and change the icon (of the shortcut) to that of firefox's.

Now each time you run the batchfile it copies files from "FirefoxPersistent" over to the "Firefox" sandbox and then runs firefox (in the "Firefox" sandbox). After use the "Firefox" sandbox can be cleared and no changes will have been made to the "FirefoxPersistent" box. I personally went further with the batchfile but above are the basics.

If you wish to update firefox or make permanent changes to the template just run it in the "FirefoxPersistent" sandbox. Personally I take a copy of the PersistentSandbox folders before upgrading so I can quickly copy the template folder back if something goes wrong or I don't like the update for whatever reason.

If you want multiple "child" sandboxes you can create extra sandboxes, eg "Firefox2" then copy/create a second batchfile which pulls from the same firefox template in the same manner. I'm yet to find a program this doesn't work on; I have Firefox, GIMP, OpenOffice, Streamlink, Kodi and a host of other software working this way.

A note: I found I needed to use the offline installer to upgrade the firefox template with this setup (may be my restrictions though). Thats why I say always backup template folders before major changes if you do the above.
Also note that it doesn't copy the entire content of the persistent sandbox, just the user settings. It actually runs firefox directly from the persistent sandbox meaning it doesn't need to copy the entire install over each time

@RooJ
I have tried something like that before, it doesn't really work well and that's why I'm making this feature request. This kind of workarounds have problems:

1. Registry files are not so large - so not really a problem.
2. User data folder could be large depends on the software you use and the way it installs
   (Google Chrome would install program files into AppData when no administrator privilege given)
3. Program files could be really large in most cases.
   Copying those file would work, but it's just a waste of time and disk space. What if the program is really large, like Steam, Photoshop... etc?

I've noticed that in your practice you didn't copy the program files, instead runs it from the real location ("C:\PersistentSandbox\Firefox\drive\C\Program Files\Mozilla Firefox") inside the "fake-child-sandbox".
I'm not sure how well this procedure would work for other programs as from their point of view, they are not running from their installation directory. Some program may work, some may have broken functions or not even start at all. I've also thought about using junctions/symbolic links but they don't work under sandbox (I can't create links in real OS as that would defeat the whole purpose)

So basically, there's no perfect workaround unless you're willing to create a full duplicate of a parent sandbox, which have nothing to do with Parent-Child structure at all - bascially it's nothing different from installing the program twice in different sandboxes.

I agree an official solution would be great, this isn't an attack on your request, and my solution isn't perfect... But I do disagree with most of your response.

it doesn't really work well

I currently have 12 different software installations using this technique. It works perfectly well for me.

I'm not sure how well this procedure would work for other programs as from their point of view, they are not running from their installation directory.

Then try it. When I first started using this technique I would select custom install and manually select the installation path to that of the persistent sandbox folder (and change reghive if needed). This way registry entries would point to the correct persistent sandbox folder so software would be running from it's installation directory. Future installs I realised this just wasn't needed for the vast majority of software.

it's just a waste of time and disk space

It takes seconds to copy user files for the majority of software I have, and my PC's around 5 years old. It takes no extra disk space as I copy to a ramdisk. Saying that, even if I didn't, clearing the sandbox free's up the diskspace. A child sandbox with different settings is always going to take up extra disk space.

What if the program is really large, like Steam, Photoshop... etc?

I have OpenOffice working this way, it doesn't require me to copy the program files over, only the user settings/registry.

So basically, there's no perfect workaround unless you're willing to create a full duplicate of a parent sandbox, which have nothing to do with Parent-Child structure at all - bascially it's nothing different from installing the program twice in different sandboxes.

This doesn't create a full duplicate, for the majority of software only user/reg data is copied. This pulls from a template sandbox on running and can be edited, played with, and deleted without touching the original template files. The issue with installing into and then editing software in a sandbox is that it takes a long time to re-install when you want a fresh sandbox. This technique allows you to experiment with software, clear a sandbox and within seconds have a fresh copy of the software running from the template/parent sandbox. So it's not really like "installing the program twice in different sandboxes". This seems to hit most of your numbered criteria which is why I posted, sorry if it's not perfect, I'm sure someone will find it useful.

Not trying to be rude but let me repeat myself:

There's no perfect workaround unless you're willing to create a full duplicate.

And I've already explained the reason:

from their (programs running in sandbox) point of view, they are not running from their installation directory.

From your experience it seems you have been pretty successful with your setup, but I have to point out that most software your listed are cross-platform which means they are very likely to be self-contained and less dependent on Windows OS, running from location different than installation folder may work for them.

But most programs I use are Windows only and very likely to break. For example, I have a Sandbox with some kind of "runtime" installed in it, and I install&run other programs require the runtime in the same sandbox to make them work. If I only copy the user folder and registry, the programs would refuse run in the "fake-child-sandbox" complaining couldn't find the runtime. Some program could also fail as some environmental variables (like PATH) is pointed to a non-exist location.

Of course, if I dig deeper, change some registry entries, modify environmental variables..., there's a good chance I got it up and run but that's just too much trouble. The reason I choose to run programs with Sandboxie is it's much easier to configure than PortableApps Suite (I pack my own programs to use it with). Just install programs into a sandbox and run it inside that sandbox, everything would work and everything is contained. There's no way to write a script that suits all the programs and even if I write a script for a specific program, one upgrade would easily break it (that's why I gave up on PortableApps Suite in the first place)

The setup you suggested is not only "not perfect" but also very limited. It explicitly requires the program being able to run when moved away from it's installation directory. As I stated before and from the years I've been playing around with different programs, some may work, some may work partially and some make not run at all.

To be clear, the point of this argument is to show this scenario needs the Parent-Child Sandboxes and can not be achieved with the current version of Sandboxie.

RadarNyan wrote: ↑

Sat Dec 23, 2017 7:03 am

Of course, if I dig deeper, change some registry entries, modify environmental variables..., there's a good chance I got it up and run but that's just too much trouble.

No pain no gain . There's been a tonne of great feature suggestions on this board but I think dev focus is entirely on compatibility at the moment. I can't remember the last time a new feature was introduced. I hope something like this is added but I have a feeling you're stuck with finding workarounds for the foreseeable future.

Have a look at these threads: (not the exact same thing, but may help)
viewtopic.php?p=124683#p124683
viewtopic.php?p=18473#p18473
viewtopic.php?p=73448#p73448

Regards,
Barb.-

thanks Barb.