Breakout non-executable files: allows specified files to be opened outside the sandbox

[gexgd0419]

Is your feature request related to a problem or use case?

I'm using an IM software inside a sandbox. Its "received files" folder is outside the sandbox directory, and it can write to the folder directly.

Usually I'd prefer to open the files in "received files" folder outside the sandbox (or inside another sandbox). As the folder is outside the sandbox directory, I can just open the files using Explorer, and they won't be automatically sandboxed. The IM software also allows to open the received files via its own UI, but as it is running sandboxed, the program used to open the specified file will also be run in the same sandbox.

ForceFolder can force all programs and non-executable files to be opened in a sandbox. BreakoutFolder can break out programs, but not non-executable files. The program used to open a file in a breakout folder still runs inside the sandbox.

Describe the solution you'd like

You can give BreakoutFolder the ability to break out non-executable files as well, just like its counterpart ForceFolder.

Also, opening files in breakout folders should work when the program used to open the file is a Metro/UWP app.

Describe alternatives you've considered

No response

[Dyras]

I really like this idea! Microsoft Photos in particular isn't all that happy to be opened in Sandboxie.

[DavidXanatos]

There are 4 factors used in the force process mechanism

1. If the parent process is sandboxed itself
2. Process Name and Process Path
3. The Current Working Directory the program is to be started in
4. The Path of a, if present, document passed as an argument to the program

When opening the file from the IM software the opening program falls certainly into case 1 and perhaps in case 3 depending on how its started by the IM software software.

I don't think this feature can be added safely, if we allow to break out anything with a given working directory, this means a malicious process can start cmd.exe un sandboxed with arbitrary parameters and hence mess with the host system any way it wants.
Allowing to break out based on the document path is also prone to the same sort of exploit.
The restriction to only naked processes and process locations is safe as long as the user does not explicitly set cmd.exe or C:\Windows\ to be broken out

What could be done however might be a workable solution would ne to hook ShellExecuteExW which receives normally only the path to the document and then decides internally with which process to open it.
This way we could have a block list for insecure extensions, like .exe;.dll;.ocx;.cmd;.bat;.lnk;.pif;.url;*.ps1, etc... and a list of document break out locations to allow unsandboxed opening of documents.

[DavidXanatos]

SECURITY WARNING: if you set a folder sandboxed processes can write to as break out folder, any malware will be able to put a malicious executable there and execute it without sandboxie protection. So please DO NOT DO THAT!!!

I think what will be needed here is a new feature BerakoutDocument where you can specify folders and document extensions which are to be broken out this way it could be sued safely as long as you don't specify *.cmd or other unsafe extensions explicitly.

[blap]

SECURITY WARNING: if you set a folder sandboxed processes can write to as break out folder, any malware will be able to put a malicious executable there and execute it without sandboxie protection. So please DO NOT DO THAT!!!

I think what will be needed here is a new feature BerakoutDocument where you can specify folders and document extensions which are to be broken out this way it could be sued safely as long as you don't specify *.cmd or other unsafe extensions explicitly.

manually specify extensions to be open will be excellent!

[DavidXanatos]

please note that this feature is now available in the patreon insider builds for the higher tiers