Sandboxie plus 0.9.0

This build is a Test build, a BETA RELEASE, testing the new functionality to use Windows Filtering Platform (WFP) to implement a per sandbox firewall.
This functionality needs to be enabled in the global Sandboxie settings, and the driver needs to be reloaded (or the PC rebooted) for the feature to be activated. Once this is done the firewall rules which can be configured in the network options of each sandbox, will be enforced by the driver.
If the WFP support is not enabled the same rules still can be set and are used, but will be applied only by a set of user mode hooks, unlike the WFP implementation they will apply only to outgoing connections and there are no enforcement guarantees as user mode hooks can be bypassed or disabled by a malicious application.

The rational behind implementing this functionality in user and kernel mode (driver) instead of driver only is twofold for once it allows for debugging of the rule processing code as booth modes use the same code to make decisions based on the preset rules. Second the WFP callouts are global i.e. they are triggered for any process on the system whether its sandboxed or not, in the lather case they don't do anything and the use of a hash map to identify sandboxed programs that require action should provide optimal performance. That said users who run a 3rd party firewall which they may prefer may not want to many firewalls being active at once, while still wanting to use some per sandbox network rules for compatibility and not security reasons.

Also please note that with this build the old "BlockPort=..." functionality is completely dropped, the default port block rules are now implemented by the new user mode firewall component, if you have custom BlockPort entries in your sandboxie ini they will need to be updated by hand to the new format, for example "BlockPort=137,138,139,445" -> "NetworkAccess=Block;Port=137,138,139,445"

The rules are applied based on a specific decision priority:

1. A rule for a specified program trumps a rule for all programs except a given one, trumps rules for all programs
2. A rule with a Port or IP trumps a rule without
   2a. A rule with ip and port trums a rule with ip or port only
   2b. A rule with one ip trumps a rule with an ip range that is besides that on the same level
3. Block rules trump allow rules
4. A rule without a protocol means all protocols, a rule with a protocol trumps a rule without if its the only difference

The rule editing UI allows for testing rules, in the row below the rule list one can enter program name, port, ip and protocol to see which rules are in play and which rule will be applied in the end.



When configuring per process network access restrictions and WFP is enabled it is possible to choose between a WFP based approach and the old sandboxie way of blocking the network device end points. The later approach is more absolute, but is know for causing some application to crash.



Download: https://github.com/sandboxie-plus/Sandboxie/releases/tag/0.9.2
Download: https://github.com/sandboxie-plus/Sandboxie/releases/tag/0.9.1
Download: https://github.com/sandboxie-plus/Sandboxie/releases/tag/0.9.0a





If you have issues with an update installation, just uninstall the previous version keeping the sandboxie.ini and reinstall the new build.

Changelog

[0.9.2 / 5.51.2] - 2021-08-07
Added

• added ability to reconfigure teh driver, allowing to enable/disable WFP and otehr features without a reload/reboot

Fixed

• fixed issue with process start handling introduced in 5.51.0 #1063
• fixed issue with quick recovery introduced in 5.51.0
• fixed incompatybility with CET Hardware-enforced Stack Protection on intel 11th gen and AMD 5xxxX cpu's #1067 #1012

removed

• commented out all windows xp specific support code
  

[0.9.1 / 5.51.1] - 2021-07-31
Added

• added tray icon indicating no connection to the driver if it happens
• added option to customize the tray icon
• added "DllSkipHook=some.dll" option to disable installation of hooks into selected DLLs
• added localization support for Plus installer (by yfdyh000 and mpheath) #923

Changed

• reworked NtClose handling for better performance and extendibility
• improved tray box menu and list

Fixed

• fixed issue with fake admin and some NSIS installers #1052
• fixed more issued with FileDispositionInformation behaviour, which resulted in bogus file deletion handling
• fixed issue with checking WFP status
• fixed issue WFP failing to initialize at boot
• fixed issue with tray sandbox options not being available just after boot
• fixed issue access changed flag not being proeprly set in box options #1065

[0.9.0 / 5.51.0] - 2021-07-29
Added

• added support for Windows Filtering Platform (WFP) to be used instead of the device-based network blocking scheme -- to enable this support, add 'NetworkEnableWFP=y' to the global section and reboot or reload the driver -- to use WFP for a specific sandbox, add 'AllowNetworkAccess=n' -- you can allow certain processes by using 'AllowNetworkAccess=program.exe,y' -- you can also enable this policy globally by adding 'AllowNetworkAccess=n' to the global section -- in this case you can exempt entire sandboxes by adding 'AllowNetworkAccess=y' to specific boxes -- you can block certain processes by using 'AllowNetworkAccess=program.exe,n' -- Note: WFP is less absolute than the old approach, using WFP will filter only TCP/UDP communication -- restricted boxed processes will still be able to resolve domain names using the system service -- however, they will not be able to send or receive data packets directly -- the advantages of WFP is that filter rules can be implemented by restricting communication only to specified addresses or selected ports using "NetworkAccess=..."
• added fully functional rule-based packet filter in user mode for the case when "NetworkEnableWFP=y" is not set -- the mechanism replaces the old "BlockPort=..." functionality -- Note: this filter applies only to outgoing connections/traffic, for incoming traffic either the WFP mode or a third-party firewall is needed -- like the old user mode based mechanism, malicious applications can bypass it by unhooking certain functions -- hence it's recommended to use the kernel mode WFP-based mechanism when reliable isolation is required
• added new trace option "NetFwTrace=*" to trace the actions of the firewall components -- please note that the driver only trace logs the kernel debug output, use DbgView.exe to log
• API_QUERY_PROCESS_INFO can now be used to get the impersonation token of a sandboxed thread -- Note: this capability is used by TaskExplorer to allow inspecting sandbox-internal tokens -- Note: a process must have administrative privileges to be able to use this API
• added a UI option to switch "MsiInstallerExemptions=y" on and off -- just in case a future Windows build breaks something in the systemless mode
• added sample code for ObRegisterCallbacks to the driver
• added new debug options "DisableFileFilter=y" and "DisableKeyFilter=y" that allow to disable file and registry filtering -- Note: these options are for testing only and disable core parts of the sandbox isolation
• added a few command line options to SandMan.exe

Changed

• greatly improved the performance of the trace log, but it's no longer possible to log to both SandMan and SbieCtrl at the same time
• reworked process creation code to use PsSetCreateProcessNotifyRoutineEx and improved process termination

Fixed

• added missing hook for ConnectEx function

 

Well, I enabled the box under Internet Restrictions "Prompt user to allow an exemption from the blockade" as I'd enabled "Block using Windows Filtering Platform." So I back-pedaled a bit out of curiosity and opted in.

My Plus UI doesn't have "Network Firewall Rules" tab, it has "Network Restrictions" instead. How come?

Spoiler

Edit: Firefox crashed immediately with the WFP enabled. Oh well. Just undid the setting and will wait for further developments.

Spoiler

 

ah yea i renamed it in the mean time, same thing though

 

This sounds neat. I might want to download and try this. So if I wanted to block all internet traffic in a sandbox for all programs, but still allow a specific program LAN access, I would need to:
1. Go into Process Restrictions and Block Access
2. Go into Network Restrictions: Game.exe Allow IP 192.168.0.1-192.168.255.255 Protocol Any
Is this correct?

 

All of a sudden, the tray icon's right-click menu is missing a few elements. Thought I would mention, and ask if this happened to anyone else on this beta build.

Spoiler

 

I've never used the old "BlockPort=..." functionality.
Curious, how were "BlockPort=..." function rule added prior to BETA build?
Curious, how were custom BlockPort entries added to sandboxie ini prior to BETA build?

 

Actually that "reduced" right-click-tray-icon-menu has already been introduced in v.0.8.9.

 

What's "reduced" right-click-tray-icon-menu in 0.8.9?
Maybe, you're thinking Run Sandboxed menu?

 

First observations on Beta-v0.9.0a:
Installed normally, then enabled WFP in "Advanced Config" and re-booted. As a consequence on each re-boot from then on the Win-UAC-promp would pop up asking for allowance to make changes by Sandman (although I am on an Admin-account). So for the time being I went back to disable WFP again as I currently have no urgent need for that new individual-firewall feature.

Then, suddenly, during normal use something must have happened that triggered an error-message which unfortunately did look all-too-familiar to me.

"opera_crashreporter.exe (2748: SBIE2101 Object name not found: Unnamed object, error ConnectPort (C0000022) access=001F0000 initialized=1"

So again that ominous "SBIE2101 Object name not found: Unnamed object" error which on my 11th-gen-Intel machine prohibits the launch of Chromium-engine->v90-browsers for months now.

Only this time around on Chromium-v89-Opera. But the good news is that I could continue browsing as normal, the term "opera_crashreporter" is misleading as the browser did launch normally and didn't crash either. I have no idea which operation has malfunctioned here except there has been mention of "ConnectPort (C0000022)" this time around.

By now I have gotten this error-message pop up for several times every now and then - but whatever operation it was that malfunctioned - it doesn't seem to impair further browsing as normal. Needless to say (as there has been no related fix) that up-to-date Chrome and Opera browsers still won't launch while MS-edge will.

And yet this is not entirely "status-quo"-behavior. Interestingly enough with Sbie-v0.9.0a those very similar error-messages when refusing to launch Chromium>v90-browsers will no longer pop-up. When clicking the Chrome- or current-Opera-icon for launching the browser I'll just get a busy-cursor for 2 seconds - and then nothing happens at all. The launch-command will just go into the void with no further reaction.

 

Here you go!
I've been talking about the appearance as compared to v0.8.8.

Spoiler: menu_v0.8.8

 

Okay....what's "reduced"?

Spoiler: 0.8.9 compared to 0.8.8

 

WFP should not trigger any UAC prompts that's very strange, somehow the driver or service must have failed to start.
What windows version do you have?

 

Well I found one bug, when you use the per process blockign scheme with WPF all apps crash because of a small oversight that will be fixed in the next build,
but the rule based filtering works just fine.

Also I tested the build on w7 x64 and there the driver also loads fine and does its job.

So not sure why @algol1 has the UAC issue

 

Well, obviously THAT is reduced!

Spoiler: v0.8.9c onward 2nd-level-context-menu

Since Sbie_v0.8.9!c! and onward to v0.9.0a my second level, 2nd-right-click-context-menu only will show THIS!
I'm running W10ProfWks_21H1 on one of those infamous "11th-Gen-Intel"-machines.

 

I'm running W10ProfWks_21H1 on one of those infamous "11th-Gen-Intel"-machines.
And I'm absolutely certain the UAC came up each time when re-booting after having turned WFP on and reversibly went away again after having turned WFP off.

Having that said, other than the annoyance of having to affirm the UAC-request on each re-boot, sandboxed operations and browsing went on as normal. So I had no indication whatsoever that either the driver or the service might not have started successfully. According to my previous experience having no driver or no service would seriously impair all further sandboxed operations.

What is possible though is that either the start of the driver or service with WFP=on for that reason somehow does require an UAC-confirmation under Win10 and therefore did trigger the prompt

Oh, and btw. all of these v0.9.0a-test-runs have been performed under an admin-account. HTH.

 

Any way to go back to the full right-click menus?

 

Maybe this change of behaviour appears when there is only the default box? I have what @bjm_ showed with more than one box

 

strange for me the menu works normally,
have you tried to first left then right click the entries?

 

As you all can see - I'm not making things up. With v.0.8.9a/b I had that same (IMHO a bit overloaded) comprehensive 2nd-level-sub-menu as depicted by @bjm.

Many users - at least on a regular basis - will only have that default box running I assume. And for all these mainstream-users I could imagine it might look a bit strange to begin with that in the "new" right-click-context-menu you have that ~8-line-void between "default box" and "terminate all processes".

As for that comprehensive 2nd-level-context-menu I'm not really missing it that much. The only thing therein I really do miss is the option to delete the contents of the last-used/default-sandbox. But to have that often-needed shortcut-option as readily available as the emergency-kill for all processes it would have to be situated in the primary right-click-context-menu, right away above the kill-processes option, as it has been the case in the classic SbieCtrl-interface (pls. don't bother to recommend a switch to the classic interface for that matter as Sandman in the meantime, thanks to Davids efforts, has clearly surpassed the SbieCtrl-interface in its functionality).

 

Well, the reason why I posted that menu snip is becuase the tiny red circle with an "X" next to "Terminate all Programs" is grey versus the normal red. Then again, Firefox wasn't open, so is that normal, I wonder?

Right now, I'm back on the prior 0.8.9. and it seems fine on the surface. Maybe I'll try cleanly installing it later on today. This was an "over-the-top" with the UI exited.

Spoiler

 

Yes I have. I'm aware that there is no auto-highlighting of the box-menu-item.

I definitely had the same comprehensive 2nd-level-context-menu until (and including) Sbie v0.8.9b. The change took place exactly with the upgrade to hotfix_v0.8.9c and is reversible. So with that hotfix something must have changed that would affect precisely the display of that 2nd-level-context-structure.

 

I can not reproduce the issue with the tray menu, can you test if its still there with 2 boxes etc?

 

Sure I can. Result: same behavior.

Spoiler: 2nd-level-context-menu 3 boxes

 

very strange.... and its always the case like opening the UI and doing something there doe snot fix the issue?
This menu as you see it would be there if no box would be selected, really strange

BRW: I found your boot issue will be fixed in the next build

 

Oh, surprise! I can now confirm that after just opening Sandman and closing it down again the full 2nd-level-context-menu will open up from the tray-icon again.

However there still must have occurred some change from v0.8.9b to v0.8.9c as until v0.8.9b the context-menu has been available right from the start, regardless of having opened Sandman before or not.

As for the UAC-issue I am glad to hear that. In the meantime I've executed a few tests myself, researching what the consequence would be if I declined the UAC-confirmation for Sandbox_Manager.

After not allowing access for Sandbox_Manager and then trying to launch the browser as usual I got:

Spoiler: error_msg_1

Spoiler: error_msg_2

Needles to say no browser would start after that. When trying to just open SandMan I got:

Spoiler: SandMan

On the other hand, after confirming the UAC-request I checked Win-services and found the Sbie-service to be running and by "driverquery"-command I could confirm that the Sbie-driver was active as well. Hence normal operation as expected.