I run mine in Sandboxie and see no issue in doing so, plus I don't think it breaks the effectiveness of Chrome's security.
Here it is again... For all practical purposes, I believe that SBIE on Chrome isn't necessary unless you're: A) A click-happy user. B) Sharing the computer with click-happy users. C) Controlling what Chrome accesses. D) Targeted by elite hackers. Feel free to add onto the list.
I believe the people who are actually qualified to answer this question either don't visit "security forums" or don't participate actively. With qualified I mean those who penetrate sandboxes for a living, since they know best what's a real obstacle and what's just smoke and mirrors.
This thread, especially post #8 and #25, the latter of which links to a 2011 Sbie thread, is a good read related to this subject.
I do. It does help chrome's sandbox and Curt from Invincea is constantly struggling to fix incompatibles among both sandboxing technologies. But yes, I think just like tzuk that Sandboxie should be combined on top of Chrome built-in sandbox.
the chrome sandbox rely on windows security mechanism -> protected mode https://en.wikipedia.org/wiki/Protected_Mode https://de.wikipedia.org/wiki/Protected_Mode Adobe, Mozilla aso. uses it (pdf, flash)
Yes but google has enhanced it by using both LOW-integrity level and untrusted integrity level, combined with Job object, alternate desktop and ACL protection on Chrome User Data. Last time I checked SBIE runs everything Untrusted. So the SBIE protections have to compensate for IL border between tab/renderer running Low-IL and for instance flash running Untrusted-IL. I am not saying that is weakening Chrome sandbox, just telling that SBIE has to add something extra to compensate the removal of the Low-Untrusted border. As for exploit vulnability, I don't buy the pen-testers reports that with SBIE it would be easier to use a bug in a predictable way, simply because SBIE has ads more hurdles to overcome. The SBIE adding attack surface is not a huge disadvantage IMO, because a lot of the extra code is (probably) directed to preventing side-by-side infections and SBIE is using intergity levels also (so IL-elevation would probably based on OS-faults). Since SBIE facilitates x64 OS-ses there is only one case of SBIE actually providing an escape outside the sandbox. [EDIT - Added explanation in regard to pen testers FUD] Integrity levels prevent a lower rights object to change higher rights objects. So Untrusted-IL (Anonymous) can't change Low-IL, Low-IL (Everyone) can't change, Medium-IL, Medium-IL (Basic user) can't change High-IL, High-IL (Administrator) can't change System. SInce V4, SBIE also uses these Integrity Levels. With x64 kernel patch protection it would be very unlikely (and also very costly to maintain) that SBIE implements IL-protection mechanisms of its own. Side-by-side infection is Windows OS not protecting one medium level process against another medium level process. Since SBIE is an application Sandbox, it is designed to protects processes against a sandbox application. Because SBIE now also uses OS-IL mechanismes, the majority of SBIE's code would be directed to containment of same IL-processes. Extra code is always a security risk, but for SBIE it is most likely that extra code (attack surface) is designed to contain the impact of side-by-side infections. So the FUD of pen-testers that an application sandbox makes it easier to bypass Chrome sandbox is IMO a bold and unlikely claim. Disclaimer: as Kees1958 I often posted critism on SBIE running process as admin in stead of basic user (in XP area) and as medium-IL in stead of low-il (Vista Area). I am not using SBIE either, so can't be accused of fan-boy-ism. You can accuse me of ranting against FUD (e.g. artificial exploit tests of MRG).
I run Chrome sandboxed because I don't want to install it on my real system, I only run it once in a while for testing purposes. When it comes to blocking exploits, Chrome probably doesn't need the help of SBIE, but as you may already know, SBIE has got other advantages.
1. The primary purpose behind a "sandbox" is to limit access to resources (repeat until you get it). In that respect, Chromium sandbox architecture is already pretty strict, given the constraints on what the OS allows developers to do. 2. I don't get the obsession with double bagging on sandboxes. Don't get me wrong. I am not criticizing Sandboxie. There is no doubt of the value that Sandboxie provides in its other features/advantages. I am criticizing the action of running Sandboxie on top of Chrome because of the false notion that 2 sandboxes is better than 1. 3. Running Sandboxie on top of Chrome does not make a stronger sandbox. To the contrary, it weakens Chrome's sandbox because of the added attack surface and the possible incompatibilities between Sandboxie & Chrome. It is a huge disadvantage because it undermines the 2 design principles behind Chrome's sandbox; namely the concept of "Not reinventing the wheel" and "Principle of least privilege". It's like moving 2 steps backwards & 1 step forward. 4. The more I try to convince people it's a poor trade-off, the more I think I am failing. Whatever...feel free to do whatever you want.
i use google chrome on linux..is the chrome sandbox in some way different in functionality than the windows version.?
The sandboxing utilized by Chromium under Linux is very robust, especially the layer 2 seccomp-BPF which helps protect the kernel from malicious user-space code. -https://code.google.com/p/chromium/wiki/LinuxSandboxing
B There are three reasons yours is a lost cause. First have you ever seen a kid playing in a sandbox without spoiling dirt outside the sandbox. So the sandbox paradigm is chosen real badly. Secondly we are talking about security as being something of a consistent state, while security in fact defines soms degree of insecurity (as there is no 100% security). To add to this confusion the some degree of insecurity is a non tangible feeling. Thirdly SBIE users refer to a sandbox as an application virtualisation sandbox, so in their opinion the Chrome sandbox is missing something (virtualisation). Although you made soms valid points, you would not be able to convince hardcore sandboxie users.
So what is the truth than regarding SBIE and Chrome combo thing, true or false if we completely disregard fanboyism? People say, truth in real life, is always somewhere in the middle-does this count for SBIE and Chrome combo thing?
CWS, there is no one here who can give you a definite answer. On my previous reply, D is only an assumption for example. Looks like I'll have to add one more thing to my list: E) Isolation of Chrome from the system. Similar to C, but more clear and specific.
Wat J_L said is true, but the problem is what Safeguy said is also true. My first answer tries to explain the point You are making: truth lies somewhere in between. Althoug sandboxie adds code and may interfere with soms chrome code, Sandboxie does use the main integrity level isolation mechanism, secondly the added code is designed to prevent side by side isolation, so it can't be bad for security. Ergo IMO truth is somewhere in between. So when you like application sandbox throwing away changes and files after a browsing session, you should use sandboxie to your own liking.
Long time no see. The thing is, let's say that SBIE breaks Chrome's sandbox (or makes it weaker), why should you care as long as SBIE does all the containing and exploit blocking, know what I mean? That's the way I look at it.
Except that SBIE could get exploited also. If attacker would specifically target unpatched SBIE vulnerability, using SBIE could allow attacker to bypass Chrome sandbox and compromise OS.
As far as I know the only thing sbie changes is the user object restriction (allowing only one sub process to Be started), because this is replaced by SBIE launch control and lingering processes control.
I don't see the problem. If Chrome gets exploited while running outside the sandbox, then your system may get infected, but if it's running inside the sandbox, hackers must try to bypass Sandboxie also. Both SBIE and Chrome make use of the same sandboxing technologies, the only difference is that SBIE can enforce sandboxing on all (or most) apps, while Chrome only takes care of itself.
... or they can get right to bypassing SBIE and by this escaping Chrome's sandbox. In this situation SBIE would present additional attack vector for hacker.
