Bot releases are visible (Hide)
Published by DavidXanatos over 2 years ago
This build is a maintenance release, fixing various issues
Published by DavidXanatos over 2 years ago
This build is a maintenance release, fixing various issues
Published by DavidXanatos over 2 years ago
This build is a maintenance release, fixing various issues
Published by DavidXanatos over 2 years ago
This build fixes a couple of issues, but also introduces a major change in how sandboxie controls access to process memory.
Before this build sandboxie allowed sandboxed programs to read the memory of any unsandboxed program belonging to the current user, this is obviously a bad idea if your goals is not only infection prevention but also data protection. Hence with 1.0.16 onwards sandboxie will not allow for PROCESS_VM_READ on unsandboxed processes or processes belonging to other boxes.
To facilitate compatibility this build introduces a IPC options, with ReadIpcPath=$:program.exe any unboxed process can be configured to allow for PROCESS_VM_READ, it is also possible to restore the old behavior entirely by specifying ReadIpcPath=$:*
By default the only process whos memory can be read is explorer.exe many processes want that and explorer should not keep any secrets normally anyways. To block this you can use ClosedIpcPath=$:explorer.exe
To facilitate optimal process isoaltion the EnableObjectFiltering option is now on by default, although this only applies for new installations, hence its recommend for existing installation to go to settings->advanced and enable it explicitly.
Other changes in this build include a simple resource access monitor mode and a change how process paths are resolved for sandboxed processes, this should fix a couple of issues.
Given that this build changes a couple of core mechanics it is possible that in some special cases this can lead to an incompatibility.
$:
syntax now accepts a wildcard $:*
no more specialized wildcards thoughPublished by DavidXanatos over 2 years ago
This build fixes a couple of issues, but also introduces a major change in how sandboxie controls access to process memory.
Before this build sandboxie allowed sandboxed programs to read the memory of any unsandboxed program belonging to the current user, this is obviously a bad idea if your goals is not only infection prevention but also data protection. Hence with 1.0.16 onwards sandboxie will not allow for PROCESS_VM_READ on unsandboxed processes or processes belonging to other boxes.
To facilitate compatibility this build introduces a IPC options, with ReadIpcPath=$:program.exe any unboxed process can be configured to allow for PROCESS_VM_READ, it is also possible to restore the old behavior entirely by specifying ReadIpcPath=$:*
By default the only process whos memory can be read is explorer.exe many processes want that and explorer should not keep any secrets normally anyways. To block this you can use ClosedIpcPath=$:explorer.exe
To facilitate optimal process isoaltion the EnableObjectFiltering option is now on by default, although this only applies for new installations, hence its recommend for existing installation to go to settings->advanced and enable it explicitly.
Other changes in this build include a simple resource access monitor mode and a change how process paths are resolved for sandboxed processes, this should fix a couple of issues.
Given that this build changes a couple of core mechanics it is possible that in some special cases this can lead to an incompatibility.
$:
syntax now accepts a wildcard $:*
no more specialized wildcards thoughPublished by DavidXanatos over 2 years ago
This build fixes a couple of issues, but also introduces a major change in how sandboxie controls access to process memory.
Before this build sandboxie allowed sandboxed programs to read the memory of any unsandboxed program belonging to the current user, this is obviously a bad idea if your goals is not only infection prevention but also data protection. Hence with 1.0.16 onwards sandboxie will not allow for PROCESS_VM_READ on unsandboxed processes or processes belonging to other boxes.
To facilitate compatibility this build introduces a IPC options, with ReadIpcPath=$:program.exe any unboxed process can be configured to allow for PROCESS_VM_READ, it is also possible to restore the old behavior entirely by specifying ReadIpcPath=$:*
By default the only process whos memory can be read is explorer.exe many processes want that and explorer should not keep any secrets normally anyways. To block this you can use ClosedIpcPath=$:explorer.exe
To facilitate optimal process isoaltion the EnableObjectFiltering option is now on by default, although this only applies for new installations, hence its recommend for existing installation to go to settings->advanced and enable it explicitly.
Other changes in this build include a simple resource access monitor mode and a change how process paths are resolved for sandboxed processes, this should fix a couple of issues.
Given that this build changes a couple of core mechanics it is possible that in some special cases this can lead to an incompatibility.
$:
syntax now accepts a wildcard $:*
no more specialized wildcards thoughPublished by DavidXanatos over 2 years ago
Published by DavidXanatos over 2 years ago
This build fixed a security issue.
Published by DavidXanatos over 2 years ago
This build fixed a security issue.
Published by DavidXanatos over 2 years ago
This build fixed a lot of various issues.
Published by DavidXanatos over 2 years ago
This build fixed a lot of various issues.
Published by DavidXanatos over 2 years ago
This build fixed a lot of various issues.
Run Un-Sandboxed
context menu optionOnBoxDelete
that allows to specify a command that is run UNBOXED just before the box content gets deletedDeleteCommand
#591
HideHostProcess=program.exe
can now be used to hide Sandboxie services #1336
StartProgram=...
makes StartCommand=...
obsoleteStartCommand=...
, use StartProgram=%SbieHome%\Start.exe ...
Auto Start
General tab with the Auto Exec
Advanced tab into a universal Triggers
Advanced tabAutoExec=...
UseRpcMgmtSetComTimeout=AppXDeploymentClient.dll,y
used for Free Download Manager as it broke other thingsRpcMgmtSetComTimeout=n
in a sandbox, you have to add the line manually to your Sandboxie.iniPublished by DavidXanatos over 2 years ago
This build fixed a lot of various issues, some of them quite old, as well as a security issue related to some internal COM workarounds.
Published by DavidXanatos almost 3 years ago
This build fixed many issues, and adds a new functionality: "BreakoutProcess=program.exe" which allows to preset programs to be able to escape a sandbox, hence this is a feature rather for compartmentalization than security. But in the way it is implemented, a breakout process will be captured by another sandbox if it is configured as a forced process for it. So a possibly security related use case would be to have a box dedicated to run your web browser only, where it is forced, and have it configured as a breakout process for all other boxes or globally. In this scenario, no matter what boxed or unboxed application starts a browser, it will always run in the browser box.
This new feature is enabled only for certified project supporters, if I reach 250 patrons it will be made available to all users, please consider supporting the development of Sandboxie-Plus: https://www.patreon.com/DavidXanatos
/remove /S
for Classic installer (by sredna) #1532
Published by DavidXanatos almost 3 years ago
This build fixed various issues with the previous build and adds some new functionality
Published by DavidXanatos almost 3 years ago
This build fixed various issues with the previous build and adds some new functionality
Published by DavidXanatos almost 3 years ago
scroll down to download this build ⬇️ |
---|
The 1.0.x line of builds is finally ready for a final release as version 1.0.5
The first major feature is Privacy Mode, here most of the PC is set to be treated like a Write[File/Key]Path meaning the sandbox locations are writable but the unsandboxed locations are not readable. The Hard disk appears empty except for C:\Windows and C:\Program Files and the registry only allows reading of the machine but not user root keys. This way sandboxed processes can work but can not access private user data.
To make this mode useful an other feature has been implemented called “Rule Specificity” it can be enabled independently but is always enabled in Privacy enhanced boxes. It allows to specify rules to override other rules, this is not based on specifying an order or priority, but instead by measuring how specific a rule is and always attributing the highest priority to the most specific rule.
Here the specificity is measures by the path length that matches the rule, except the last wildcard.
So for example the built in privacy rules plus a custom one
OpenFilePath=%AppData%\Mozilla\Firefox\Profiles*
NormalFilePath=C:\Program Files*
NormalFilePath=C:\Windows*
WriteFilePath=C:*
Here the rules are ordered by their specificity.
Also there is a new type Normal[File/Key/Ipc]Path which defines a default sandbox behavior for a path.
The next major feature is "App Compartment" mode "NoSecurityIsolation=y", this is a new mode of operation which disables the token based security isolation, which brings the security down to the level of other sand boxing solutions, but by doing so greatly improves compatibility. For all use cases where the goal is only compartmentalization, running multiple instances, etc, but not hard core security this mode is preferable as it should avoid many typical sandboxie issues caused by processes running with a heavily restricted token.
In this mode file system and registry accesses are still being filtered to enforce the access rules, this filtering can be disabled with "NoSecurityFiltering=y"
To ensure this “unsecure” mode is at least as secure as the sandboxing offered by other sandboxing products, a new object access filter was added that can be enabled with "EnableObjectFiltering=y" in the global settings.
C:\Sandbox\%USER%\%SANDBOX%
added Privacy enhanced mode, sandboxes with "UsePrivacyMode=y" will not allow read access to locations containing user data
-- all locations except generic Windows system paths will need to be opened explicitly for read and/or write access
-- using "NormalFilePath=...", "NormalKeyPath=...", "NormalIpcPath=..." allows to open locations to be readable and sandboxed
added new "App Compartment" mode of operation, it is enabled by adding "NoSecurityIsolation=y" to the box configuration
-- in this mode, security is traded in for compatibility, it should not be used for untrusted applications
-- Note: in this mode, file and registry filtering are still in place, hence processes run without administrative privileges
-- it is reasonably safe, all filtering can be disabled with "NoSecurityFiltering=y"
added experimental use of ObRegisterCallbacks to filter object creation and duplication
-- this filtering is independent from the regular SbieDrv's syscall-based filtering, hence it also applies to App Compartments
-- with it enabled, an application running in a compartment will not be able to manipulate processes running outside the sandbox
-- Note: this feature improves the security of unisolated App Compartment boxes
-- to enable this feature, set "EnableObjectFiltering=y" in the global section and reload the driver
-- when globally activated, the filtering can be disabled for individual boxes with "DisableObjectFilter=y"
added "DontOpenForBoxed=n", this option disables the discrimination of boxed processes for open file and open key directives
-- this behaviour does not really improve security anyways, but may be annoying, also app compartments always disable this
added setting to entirely open access to the COM infrastructure
Published by DavidXanatos almost 3 years ago
System call hooking for Win32k system calls is now enabled by default, it is still used only for a hand full of calls currently, as required to get chromium Hardware Acceleration acceleration to work properly. This feature now also works for 32 bit applications running under WoW64.
This feature can be configured here, if you would to experience SbieDrv.sys related BSOD's try disabling it:
Published by DavidXanatos almost 3 years ago
This build introduced a new major feature, system call hooking for Win32k system calls, it is used only for a hand full of calls currently, and is currently not working for 32 bit applications running on a 64 bit host, that limitation is being worked on.
This feature resolves the Hardware Acceleration issues with Chromium based browsers, it can be enabled like this:
Published by DavidXanatos almost 3 years ago
This build fixes bugs introduced recently