Does Sandboxie have self-protection?

Sully,
It was just a quick test, not a "proper" experiment by any means. The closest real world equivalent would be seeing what's possible should malicious code escape the sandbox and attack it from the outside.

I'm suspecting that they won't be terminated. If an app that has built in resistance to termination can be made to run inside the sandbox, it could make for some very interesting experiments.

IMO, a layered approach in which a separate app protects the Sandboxie processes and files, plus restricts the allowed activities in the sandbox itself is the way to go. No matter how well an app is coded, it's not bulletproof. Just because there isn't a publicly known way to attack and defeat it doesn't mean it's impossible. A means might not be found or it may be found tomorrow. For all we know, just such an attack might have been found and sold to those who collect these things (government agencies and the private sector companies that do the dirty work for instance). When your security policy and package acknowledge possibilities like this and proactively address them, unpatched and zero day exploits against the protected apps are often mitigated or defeated outright. I haven't seen and am not aware of any attacks that can terminate my firewall or SSM, but both are watched and will be restarted if something does terminate one of them. Sandboxie is good and may be able to stand alone, but why should it when it doesn't have to?

 

If you exit SBIE, even if the sandbox is set to have the contents deleted automatically, the contents of the sandbox will not be deleted until you restart Sandboxie and click on delete the sandbox.

Bo

 

This thread has started from a fairly unfortunate premise in my view. I understand the concern but it is based on a misunderstanding on how SBIE works in my view.

Sully has, as always, laid out the fundamentals on which SBIE works. I wonder at times if it is so simple that it confuses things and we see SBIE through the prism that we use for traditional security apps. SBIE is part of a different paradigm than that associated with traditional AV/HIPS or similar.

Other apps work similarly. Take Defensewall for example. An trusted programme can kill it easily. That's the point. Only untrusted apps are restricted. With AppGuard un-guarded apps can do what they like. In SBIE anything unsandboxed will be able to kill SBIE processes, albeit needing privilege elevation at times. Trying similar tactics within the Sandbox would be pointless as if you kill SBIE you kill the app undertaking the malicious activities. Not to mention SBIE restricts many activities by default and when configured with start/run restrictions would prevent malicious/unauthorised execution anyway.

For it to be a genuine concern for me someone is going to have to prove a malicious app can escape SBIE control and write to the host, execute and kill SBIE from outside the sandbox. Until I see that I know anything running unsandboxed might be able to attack SBIE. The whole point of SBIE is to keep such things safely locked away. If you let that stuff out of the sandbox without a strategy to confirm it is safe or further restrict it, well you deserve what you get.

Cheers

 

Excellent post!

 

If you close or exit the browser, of course the sandbox is deleted automatically. On my previous post, I said "Exit Sandboxie". If you exit SBIE, killing SBIE processes, the contents of the sandbox dont delete automatically. The contents wont escape the sandbox but they have to be deleted after restarting Sandboxie.

Pete, check it out and you ll see what I mean. Open your browser sandboxed, exit Sandboxie, close Firefox and after you ll restart SBIE, you ll see that the contents of the sandbox was not deleted on closing.

Bo