Sandboxie-Plus v1.8.0

This build introduced a couple of major changes to sansdboxies inner mechanics, all preset access directives have been moved to template entries. Sandboxie now fully isolates the NT namespace reducing the potential attack surface. Last but not least a couple of compatibility fixes should improve the use of chrome and chromium based applications.

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

Changelog


Added

• Run menu now supports folders, to be used by entering foldername1\foldername2\entryname in the name column of the UI
• added a tray indicator for pending updates
• added virtualization for CreateDirectoryObject(Ex) and OpenDirectoryObject (improves security, prevents name squatting) -- note: this can be disabled using 'NtNamespaceIsolation=n'

Changed

• 'OpenProtectedStorage=y' has been replaced with a template
• moved all built-in access rules to a set of default templates
• moved WinetCache control to a template OpenWinetCache, 'CloseWinetCache=y' is now obsolete
• added hook for CreateAppContainerToken, which should also improve compatibility with other apps #1926 -- note: Template_Edge_Fix is no longer required
• replaced a few icons
• moved the "Support" global settings page above the "Advanced Config" page and renamed it to "Support & Updates"
• when dragging and dropping a file on the SandMan UI to run it, the currently selected box will be pre-selected in the box picker dialog
• improved access rule handling #2633
• SbieCtrl now uses the new update format when checking for updates
• added priorization of primary matches over auylairy matches to rule specificity

Fixed

• added AppContainer support for Compartment type boxes
• FIXED SECURITY ISSUE ID-22 NtCreateSectionEx was not filtered by the driver
• fixed issue starting services without a system token
• fixed issues with new file migration settings #2700
• fixed shell integration on ARM64 #2685
• fixed new issues with driver verifier #2708

 

For some reason I cannot download version 1.8.0, the link with the 1.8.0 tag leads to version 1.7.2.

 

fixed

 

Thanks!

 

Same here.

 

I'm glad to hear that as this build really changes quite a few things so has a lot of potential to break something.

 

I don't know why but when using Edge in blue box sometimes it doesn't start properly. I haven't had this problem with other boxes. (Not specific to 1.8.0)

 

Thank you for v1.8.0 Apparently, this build introduces ConfigLevel=10.

Is this also related to "improved access rule handling #2633"? Could you provide an example of its use? Thank you.

 

So let say you have a rule C:\Windows\*
When you are accessing the windows folder itself the path that will be passed to the access check function will be C:\Windows not C:\Windows\
Only when you access a sub path C:\Windows\Something.abc you will get the \
So sandboxie when matching a path to a rule first tries the path as is and if that does not match it appends a \ to the path and tries with that
such that if you have a rule for C:\Windows\* it will also match C:\Windows itself

Now with that change if you have a rule for C:\Windows\* and an other one for C:\Windows the match of the first rule will be overruled by the match of the second rule.

In the particular use case the goal was to allow access the root of a drive but protect the sub folders
UseRuleSpecificity=y
WriteFilePath=E:\*\*
OpenFilePath=E:\*
So files on the root drive should match the open file path but not the write file path, only files in sub folders should match the write file path,
without the fix however files on the root got a \ appended to their name and matched the write file path as well resulting in them not being accessible.

 

@stapp i see there was some confision with the old 1.0.10 thread, should I in future make the thread titles contain the release date?
like: "Sandboxie Plus v1.8.0 (Feb 2023 release)"

 

Firefox just updated to 110.01. I mention this only b/c of the new gpu sandboxing feature and how some were having problems with that. I read the changelog and nothing mentions any changes related to the gpu sandbox. I'm continuing to keep this enabled and Plus v. 1.8.0 is running very well overall.

Hopefully things get sorted otherwise but I'm enjoying this combo at the moment. Runs well.

 

Thank you for your detailed explanation! Two follow-up questions:
Q1: Will the above code work correctly only in v1.8.0 (and above) because of the new fixes?
Q2: If using such code in a privacy (blue) box (with UsePrivacyMode=y),
is the line 'UseRuleSpecificity=y' redundant (because privacy mode invokes rule specificity)?

 

@DavidXanatos, I believe @busy and @stapp may be experiencing another manifestation of the problem I reported on github (https://github.com/sandboxie-plus/Sandboxie/issues/2588) where I experienced intermittent Firefox startup problems beginning with SBIE+ 1.5.3 in boxes with data protection (ie, with UsePrivacyMode=y).

I have also experienced intermittent startup failures for both Edge and Chrome starting with 1.5.3, but Firefox is my primary browser and I rarely use them.

Based on a lot of testing, it seems that 1.5.3 introduced some sort of timing issue or race condition such that Firefox, Edge, Chrome and other applications sometimes fail to start properly and I've confirmed the problem still exists in 1.8.0.

I was able to find a workaround that eliminates the startup failures for me on my 2 drive laptop (Windows 10 21H2). I created a local template to use in sandboxes configured with UsePrivacyMode=y :

Spoiler

[Template_Local_PrivacyBase]
Tmpl.Title=PrivacyBase
Tmpl.Class=Local
# Drives
ClosedFilePath=C:
ClosedFilePath=E:
# Allow access to important system folders
NormalFilePath=%SystemRoot%
NormalFilePath=%ProgramFiles%
NormalFilePath=C:\Program Files (x86)
# Registry
WriteKeyPath=\Registry\User\*

For me the ClosedFilePath along with the appropriate NormalFilePath and OpenFilePath statements eliminates the intermittent startup failures in boxes where UsePrivacyMode=y is used.

 

1 yes
2 yes but it wont hurt to have it redundant

 

Privacy mode already does the following by default.

Code:

WriteFilePath=*
NormalFilePath=%SbieHome%

+

Code:

# Allow access to important system folders
NormalFilePath=%SystemRoot%
NormalFilePath=%ProgramFiles%
NormalFilePath=C:\Program Files (x86)
# Registry
WriteKeyPath=\Registry\User\*

The only difference I see here is that 'ClosedFilePath' is used instead of 'WriteFilePath' for selected drives. Have you tried using 'WriteFilePath' instead of 'ClosedFilePath'? Does it give the same error?

Code:

WriteFilePath=C:
WriteFilePath=E:

Spoiler

 

Note that v1.8.0 "moved all built-in access rules to a set of default templates"
The default for a privacy enhanced (blue) box is:

Code:

# From v1.8.0 Templates.ini
#
# Access rules for privacy enhanced boxes
#
[TemplatePModPaths]
#NormalKeyPath=HKEY_LOCAL_MACHINE\*
#NormalKeyPath=HKEY_CURRENT_USER\software\Microsoft\*
#NormalKeyPath=HKEY_CURRENT_USER\software\WOW6432Node\Microsoft\*
#NormalKeyPath=\REGISTRY\USER\*_Classes\*
WriteKeyPath=\REGISTRY\USER\*
#
NormalFilePath=%SystemRoot%\*
NormalFilePath=%SbieHome%\*
NormalFilePath=%ProgramFiles%\*
NormalFilePath=%ProgramFiles% (x86)\*

I don't see "WriteFilePath=*". Perhaps it is also applied? [ @DavidXanatos knows for sure ]

 

Code:

if (ok && proc->use_privacy_mode) { // in privacy mode all drive paths are set to "write"
https://github.com/sandboxie-plus/Sandboxie/blob/829896cf89db66500892ae2d505729a1cc43eed6/Sandboxie/core/drv/file.c#LL840C41-L840C41