No, just choose what to use and what not. If benefits are higher than risks and you like it, by all means, use it.
Exactly and given the fact I can't measure the "risks" involved in the use of Sandboxie as I am no expert or scientifically test testimonies of other users too regarding Sandboxie's effectiveness which I "believe" with little education, I choose SBIE over the top of Chrome.
If they have the skills to bypass SBIE, they can do the same with Chrome. Don't get me wrong, I'm not saying that people should use SBIE on top of Chrome to stay secure, I'm just saying that the people that choose to do so, are still pretty safe, even when the "attack surface" may become slightly bigger.
Like WS said, that increased attack surface can sometimes even help and can be more beneficial than harmful when it comes to security and protection on top of Chrome (it depends) when it comes to SBIE protecting Chrome's sandbox (WS gave some examples in explanation, you should ask him for more details), this is why I said the real truth is somewhere in between/in the middle. Sometimes is good, sometimes is bad. Hopefully Sandboxie will work on my Windows 10 when I buy it and install it in October on my completely new/fresh computer, which I will also buy in October.
It's quite simple, some people say that SBIE might interfere with Chrome's sandbox, but Chrome won't break SBIE's protection, so you are still protected. And this whole "attack surface" thing is not interesting to me, it sounds a bit silly.
+1 To me too! In that case lets use no security software at all... to reduce to zero the attack surface.
Exactly, this is 100% true/correct. And the best thing to completely reduce attack surface to 0/zero, we should all disconnect from the internet once and for all!!!! Yeah, right... My apologies, Rasheed and Mister X I just could not help myself-that's the blame of increased attack surface (my honest apologies for bad jokes). But you are both 100% correct, as WS is.
Unfortunately chrome does not sandbox your %userprofile% from unwanted "nasties". The parent process (broker) has rights to "user" areas (usually). Click the wrong link/button, even careful users, and you just got unwanted "nasties". (you define nasties, theres many types) Other scanners and utilities could mitigate this, true. Sandboxie would contain it though, so that rather than googling how to "get rid of" that nastie, you can just delete the sandbox. Chromes ability to keep a nastie that would affect the system has nothing to do with a user (or compromised website) doing "normal stuff" in %userprofile%. Neither does Sandboxie, only that Sandboxie makes it really easy to cleanup the mess when it does happen. Sul.
Thanks for replying. I do agree with you. It does seem like my viewpoint is a lost cause but here goes anyway: 1. We are not kids here. The sandbox terminology can be confusing but in essence, sand-boxing is primarily a mechanism to restrict an application. 2. To quote Bruce Schneier: "Security is both a feeling and a reality, and they're different. You can feel secure even though you're not, and you can be secure even though you don't feel it." https://www.schneier.com/blog/archives/2008/04/the_feeling_and_1.html Most people make trade-offs based on feeling instead of reality. I am guilty of it too. Since we are in a forum discussion, I would rather we look at the reality and start making better trade-offs. 3. There's benefit to having virtualization (such as making it easier to test things and to clean up) but application virtualization in itself does not pose as a great obstacle/hurdle when it comes to securing objects.
My gripe here is people still insist on sandboxing an app that already has a native sandbox. Chrome's sandbox has proven itself to be pretty strong. The renderer tabs run with very little privilege and access. Any weaknesses found are usually fixed pretty quickly. The chances of a Chrome sandbox escape in the wild is minimal. Sandboxie, a 3rd-party sandbox, uses the same Windows security model to achieve it's sandboxing effects. However, it can only do so with a driver and by injecting DLL. This in itself poses a liability to the sandboxing mechanism as it may introduce new attack vectors - e.g. a backdoor to migrate other processes or to access the file system. I can see where there may be benefits in using Sandboxie. For the benefit of discussion, let's assume an instance whereby Sandboxie having the potential to "save the day" for a Chrome user. Now, consider the 2 drawbacks below: 1. Sandboxie's sandbox conflicting with Chrome's own sandbox 2. Sandboxie's injected DLL posing a liability to Chrome's sandboxing mechanism This is where it gets complicated and where we disagree. I am of the opinion that people are putting too much hope on a positive outcome while disregarding 2 obvious drawbacks. That is a poor trade-off in assessing risks.
The way I look at it is this: Let's say that without Sandboxie, a Chrome sandbox escape is not possible... Yet with Sandboxie, it becomes a possibility... Then Sandboxie becomes a HUGE liability in this instance. I don't care if Sandboxie manage to contain/block the exploit later on. The fact that it caused Chrome's own sandbox to fail is not acceptable to me. To play devil's advocate...why not? If my system is relatively secure without using so-called "security" programs, why should I add them in? Just to make myself feel secure? Layering for the sake of layering is not wise. I've been there, done that before. I would rather look at where the threats lie, assess my risk (how much is acceptable) and take the necessary precautions to secure my system. Not just blindly add code.
If SBIE had contained the exploit at the expense of chromes own sandbox being exploited, what would you be not accepting exactly? The fact that SBIE had stopped an exploit? Isn't that what everyone is after at the days end, a way to have some form of security? What does it matter how you achieve it really, if it works for you? I just thought it was sort of strange that if something worked but not in a way that you like, it would not be acceptable. But then, its a computer, with customized hardware, software and settings not to mention different user habits so none of it is going to be "the defacto standard way of doing it", neither in the security realm or any other realm At least people are still trying. I gave up myself.
Whoa! Sully is in the building! (In order to stay on topic... Hello, my name is Page42 and I like to run Chrome inside Sandboxie.)
The impact is, essentially, 0. No one bothers attacking Chrome, no one bothers attacking Sandboxie. If they do attack, both will probably fail at the same time as they work in similar ways and the cheapest attacks would certainly bypass both (kernel vuln). Sandboxie objectively adds attack surface, and could at the very least provide gadgets or interesting functions to an attacker, if not outright information leaks or more serious vulnerabilities of its own. Sandboxie objectively limits certain attacks against Chrome - design issues with the broker that involve only Chrome code and are not sandbox-agnostic. The reality is it just doesn't matter. The weaknesses are not in these two programs or their sandboxes, they're elsewhere - the kernel, within the browser/ websites, phishing, SE, etc. Addressing these issues will do more for your sandbox than almost anything else.
Hungry Man!!! Nice to see you bro, hope you are doing well, pm me sometime if you can. Also yes I agree with your post, the weaknesses are not in those two programs they are as strong as they can be without the kernel changing or a different OS such as Linux(chromes sandbox is stronger ofc).
http://arstechnica.com/security/201...y-potent-enough-to-infect-actual-chrome-user/ If it is really true that the exploit was bundled with attacking another Windows vulnerability, the question is if Sandboxie would have prevented it. BTW, in other reports I had read that the Linux version was also affected. IMO, it's not clear, though, if that flash vulnerability would have been exploitable as the Linux sandboxes used by Chrome are stronger. Nevertheless, running Chrome/Chromium in Firejail and have it confined by a tight AppArmor profile is certainly not a bad idea. Edit:
According to the link you posted: "The exploit, which was triggered when targets visited a booby-trapped website, remotely downloaded an encrypted file onto the target's computer, where it was then executed" Using Sandboxie, you can restrict the programs that are allowed to run in the sandbox. If you are running Chrome in a restricted sandbox and you land in an infected webpage, the malware wont run, you wont even know that you were close to getting infected. Besides that, the Drop Rights setting in Sandboxie would keep the malware from installing in the sandbox. .....this reminds me of Tzuks comment about running Chrome under Sandboxie. http://forums.sandboxie.com/phpBB3/viewtopic.php?f=5&t=11788 Bo
I know what you mean, but I don't believe that SBIE will make it easier to bypass Chrome, and if it does, you're still protected. Don't forget that SBIE is also designed to protect browsers without any sandboxing mechanism, I use it to protect Opera 12 and Firefox. This "attack surface" thingy is all (or mostly) theory. Let's get real, how many people get exploited via security tools? I've never read about it.
Yes I agree. It depends on whether the exploit that was used to bypass Chrome's sandbox, can also bypass Sandboxie. That would indeed be interesting to know.
First and foremost, welcome back Sully. It's been a long time. For your benefit, let me make myself clear. I mentioned a theoretical scenario just above the words you quoted. When I mentioned "I don't care", I meant it within the context that the exploit would not have been successful in the 1st place, just with Chrome alone. Sandboxie containing it after the fact, while is a nice result, does not take away from the irony.
With alternative browsers, Sandboxie may play a pivotal role. With Chrome though, Drop Rights is pointless. Chrome's renderer tabs are already running with Untrusted IL and with much lower access/privileges than that. As for Tzuk's comment, it was in 2011. That was prior to V4 being released. Back then, Sandboxie was using a different method (extending the kernel) to achieve it's sandboxing effect. It may (or may not) have helped. But with Sandboxie V4 onwards, it's a different story altogether.
