Curt@invincea wrote:To respond to your original point, I don't think this is something we want to add to Sandboxie. The design of Sandboxie is to allow applications in the sandbox to run freely, but to contain them within the sandbox. Adding restrictions will just cause more compatibility issues.
I kindly ask you to reconsider this again.
Hardening the Applocker/SRP by means of SandBoxIE's handling of said flags and parameters is perfectly in-line with the already existing SandBoxIE's measures like the "Drop Rights" and all the features managing the inter-process communications (Resource Access->IPC/Window/COM). Just like those measures - this could be also optional.
I strongly believe that applying those SRP-hardening measures would provide more robustness to SandBoxIE's containment capabilities.
It is clearly stated in MS's documentation that the only valid reason for Applocker/SRP bypass is the software installation process. No compatibility issues would arise from it for running the already installed
programs under SandBoxIE - I'm talking about the non-malevolent/exploit sort of programs.
Any "compatibility issue" would therefore constitute a successful exploit prevention.
In my scenario I install the software I use to the outside of a sandbox, I almost never install things within a sandbox.
My scenario is about further hardening the every-day usage security of the already installed software running under the SandBoxIE's supervision, as an additional defense measure against any 0-day threat.
Please have a look into this again.
Thank you in advance.
winXP-SP3 hacked into POSReady2009.