Sandboxie-Plus v1.11.3, v1.11.4

Release Notes

This is a maintenance release fixing a few issues, and updating the 7z library to 23.01 which fixes a security issue present in previous versions of this library.

It also adds a mechanism to backup and restore the header of an encrypted box image container, if you intent to store important data in a encrypted box, in addition to an external backup of the date themselves, it is recommended to create a header backup as well. Although be warned, the password being entered relays to the header hence restoring a header from before a password change will require the old password to be used to mount the container.

Download: https://github.com/sandboxie-plus/Sandboxie/releases/tag/v1.11.4
Download: https://github.com/sandboxie-plus/Sandboxie/releases/tag/v1.11.3

[1.11.4 / 5.66.4] - 2023-10-06
Changed

• improved behaviour with Lock All Encrypted Boxes option #3350
• fixed typo in option name: 'NoRestartOnPAC' becomes 'NoRestartOnPCA' 0e175ee

Fixed

• fixed issue with unmounting protected images #3347
• fixed issue with highlighting not being able to be turned off in the Sbie Messages tab #3338
• fixed issue with programs installed in the sandbox not being displayed via Run from Start Menu #3334
• fixed issue with NtQueryDirectoryObject #3310
• fixed Some GUI functions use the wrong box path if the FileRootPath value starts with Volume{GUID} #3345
• fixed If a program is run on RAM and Encrypted boxes when the sandbox root folder is not present, the programs will not run #3349
• fixed Process Restrictions enable/disable not working correctly #3355

[1.11.3 / 5.66.3] - 2023-09-27
Added
added container header backup/restore option to the option windows

Changed

• updated 7z library to version 23.01 4ee1464

Fixed

• fixed incorrect text display when changing the password of encrypted boxes or when exporting encrypted boxes #3296
• fixed image files not being create as sparse files

 

First observations:
The strange behavior after installing/upgrading without selecting to start the Sandman-UI (checkbox) as full window as described last time still exists. No colored border, no file-recovery for downloads, no option to start directly to the systray (for upgraders) yet. Just saying.

Also I'd like to re-iterate my suggestion in the previous forum-section about a special "breakout"-option for temporarily handling very-large file-downloads in connection with (inevitably size-limited) RAM-drive-boxes
https://www.wilderssecurity.com/threads/sandboxie-plus-v1-11-2.452365/page-4
as it came "late in the game" and may have gone unnoticed by the author over there.

 

Yea I did not have time to fix the installer script, I got a flue last 2 weeks and that resulted in massive loss of productivity,
also I missed the suggestion, sorry about that.

This is a very good idea, the implementation is however not trivial at all.
That is because when we start with a download we don't know how big it will be, that is the browser usually knows but it does not communicate this to the under laying file system API up front.
A mechanism which when a file is being written to, checks for a pre-configured file limit size, and then tries to break the file out of the box, would probably not work without significant changes, as windows does not offer an API to move an open file from one volume to an other. Meaning we would need to close it copy/move it and then re open it, that would invalidate all file handles the browser (or any other app) holds.
To make it work we would need to hook every single function that takes a file handle and implement a full handle value abstraction layer, which is probably quite an error prone endeavor as there are many non obvious windows API's which may take a file handle as part of some more complex input structure, but only in very exotic cases, so I could look into that in a more distant future.


I think there are a couple of less sophisticated solutions to this issue,
1. One could configure a designated large folder as OpenFilePath= and allow boxed processes save downloads there, the user would just need to remember to pick that folder when downloading a large file, for the security aspect, I think configuring the same folder as a ForcedFolder= should take care of making it safe.
1b. One could configure the download folder as OpenFilePath=C:\Users\[User]\Downloads\*_UNBOX_* this would allow the user to decide if a download in that folder (or its subfolders) gets boxed or not, attaching _UNBOX_ would make it break out of the sandbox in this folder location. For this to work best we should look into improving the force process mechanism to allow for wildcard syntax when configuring force process.
2. I could add a mechanism to make an encrypted box behave transient like a RAM Disk, by simply mounting a new fresh empty image created with a randomly generated password which is not being stored any ware, that would keep the space use on disk but practically as secure as having the data on a RAM Disk.
3. I could add some preset mechanism to quickly switch box root folder locations, but I'm not sure if that will not introduce more confusion than it would help, also it adds the opportunity to leave a lot of forgotten box roots laying around.

Any thoughts on these options, which one sounds best fro a users perspective?

 

This was also suggested by @busy in his reply to @algol1
I prefer this way because it is so easy to implement and it works!
I download large files using opera.exe (one of my several browsers).
My RecoverFolder is D:\Download. It is also also set as ForceFolder.
I use OpenFilePath=opera.exe,D:\Download to implement this.
Downloads from other browsers follow the usual recovery prompts.
This configuration is "set it once" and forget. Nothing complicated.

Hope you are now fully recovered from the flu

 

Sorry to hear about that flu-mishap and sincerely hope it has not been "COVID23" with all its possibly nasty side-effects and long-term consequences.

Yes, I agree, some more simplistic solution will have to do here which would avoid any "Windows-API-hacks". As an intermediary solution I've already declared such a breakout-folder, as suggested by @busy, with an OpenFilePath=statement to adapt large files that would otherwise overwhelm the RAM-drive.

Only drawback so far is that I either have to ALWAYS let files directed to that location break out of the box or I would have to endlessly re-configure the box to-and-fro to adapt to the respective download-endeavor.

So my initial idea - as already expressed in my answer to @busy - would have been to make such an OpenFilePath=statement dependent on file-size by declaring some threshold-value. Unfortunately I'v learned from your above remarks that the size of a file going to be downloaded is not known in advance, at least not outside the browser.

So perhaps a remedy would be to introduce a new "ConditionalOpenFilePath=statement" that would act the same way as the original "OpenFilePath=statement" - with the one exception that each time such a "ConditionalOpenFilePath" is about to getting used / being written to (for the first time within each session) a pop-up-message would come up letting the user decide if that path should be treated as open for the coming operations/for that session - or not.

This way the user could decide from time to time when storing a download to that special location if its size would demand a breakout from the box via an "OpenFilePath=" or not without having to adapt the whole box-configuration to-and-fro in advance.

 

I tested the new version 1.11.3 with reference to the 2 errors, which i announced here in the thread for v1.11.2, but the errors are still there. I hope, they can be fixed in a future version.
https://www.wilderssecurity.com/threads/sandboxie-plus-v1-11-2.452365/page-3#post-3163739
https://www.wilderssecurity.com/threads/sandboxie-plus-v1-11-2.452365/page-3#post-3163958

 

Where exactly to find/look for this option?

 

its a sub button of the password change button

 

booth bugs will be fixed in the next build, fixes already committed to github

 

Don't worry just a common cold, unfortunately rhino viruses are impervious to regular hand sanitizer and can survive very long on surfaces, unlike corona or influenza and many others.
So why the later can be avoided with reasonable afford, the former really can't.

That sounds like a workable solution, also the query prompt could ask if the answer is for one file, one process, or for the entire session, although I would call it ConditionalFilePath=statement as the implementation would also allow to choose at least closed.

Will put it on my ToDo list...

 

The name of course is entirely up to you, I don't even "take pride" in having "invented" the term "ConditionalXXX=" as that term may sound a bit clumsy and was only meant to illustrate my intentions. So perhaps "ChoiceFilePath=" or simply "SpecialFilePath=" would also be a naming option for that.

 

New update: https://github.com/sandboxie-plus/Sandboxie/releases/tag/v1.11.4

Full Changelog in the first post

 

Does download the new version 1.11.4 via internal updater but does not update (Help > Check for Updates). Downloaded via Github.

 

should be fixed now please try again

 

Already updated by downloading via Github. Maybe stapp could test this.

 

First observations on 1.11.4:
This time I had my premiere with the built-in updater. When opening Sandman I got an info-popup about the new maintainance-release and the offer to download and then install.

The installation seemingly went witout issues but I found it a bit odd that no Sandman seemed to start during installation - neither full window (which I do not like very much) nor (as expected) to the SysTray.

When then starting my forced default-browser (via the start-icon pinned to taskbar) still no Sandman-icon would appear in the tray. A look into my file-manager told me that the box had correctly been "outsourced" to RAM-drive R:\ though. BUT: again no yellow (colered) frame around the box, the hash-symbol although was shown in the title-bar of each browser-window, and to make things worse whenever downloading a file the successful download was never offered for recovery. Neither for immediate rec. nor at the end of the session before finally closing the sandbox. Needless to say that after the final close of the box all downloads were gone from the RAM-drive for good.

 

Another observation that probably has nothing to do with 1.11.4 at all. But still - I just upgraded to the latest edidion of Mozilla Thunderbird (v.115.3.1), an offline mailer which I only rarely use. So my last update may have been half a year or so ago and had been executed with Sandboxie-forcing paused. After that Thunderbird ran without issues even when sandboxed.

Now after the upgrade to v.115.3.1 - which again went well with Sandboxie-forcing paused and full access to my mail thereafter - when calling Thunderbird again, this time sandboxed, all I would get is a plain white screen with nothing to read, no menu or other control-item visible, nothing except an equally white-only center-popup-window on top asking for my Thunderbird-mail.password (as usual) but without any mask or line to enter that password.

Since there are no toolbars or buttons visible in the title-bars either all I can do from there is killing the Thunderbird-process by the task-manager or by Sandman-emergency-button.

Has anyone encountered such behavior of Thunderbird in the past, too? Or is it perhaps only some config-issue within Sandboxie, perhaps some necessary OpenPath-statements which will not be generated by a proper template automatically?

 

Ok, forcing programs/folders doesn't seem to currently work at all. I just exited Sandboxie altogether to experimentally open the file-paths for Thunderbird by manually editing the ini-file. So far these efforts have shown to be in vain.

But when then again opening my (forced) browser via the yellow/red "start-sandboxed"-icon - without manually and explicitly launching Sandman beforehand - the same behavior as observed after initial auto-upgrade will become visible: no yellow border, no file-recovery for downloaded files.

 

@algol1

Can you try with

Code:

UseNewSymlinkResolver=n

or

Code:

NoRestartOnPCA=y

.

 

Yes, the second statement declared in the "GlobalSettings" did the trick! Whereas the first statement made no difference.

How would you know? And what is the special meaning of those?

So Thunderbird now starts normally again. For the other problem, Sandman not autostarting when forced browswers are called that is, these two made no difference at all - but you didn't expect that, right? The advice above was only meant to get Thunderbird running - which it did. Thanks a lot for that hint.

 

@algol1

Is the Start UI when a sandboxed process is started setting checked?
(Sandboxie-Plus > Options > Global Settings > Shell Integration > Start UI when a sandboxed process is started)

UseNewSymlinkResolver [Turns the new symbolic link resolver on or off. Default: UseNewSymlinkResolver=y]
This setting has been added to address this issue.

NoRestartOnPCA [This setting determines whether the Program Compatibility Assistant (PCA) workaround is used. Default: NoRestartOnPCA=n]
This setting has been added to address this issue. It appears that some applications may not start properly as a result. (bug? @DavidXanatos)

 

Had to uninstall first as SbieDrv.sys could not be updated. Then after install it started in portable mode, and eventually after granting admin rights it finished. Also explorer/run sandboxed not working as I type this. And had to re-enable start with Windows manually.