Sandboxie and Google Chrome

[HungryMan]

~edit~

[tzuk]

Alright guys, let's try to cut down on the negativity here. HungryMan, I can agree with your 1,2,3 points summary, because at last that is a fair and balanced summy . I agree that all software has potential to be exploited. In fact let me quote something I said in another topic.

As for running more or fewer security apps, that's your decision. Clearly every additional piece of software that you introduce to your system adds more security risks. And let's suppose that some security software that you add has an unknown exploit hidden somewhere. What if that expoit is never actually exploited, but that security software does protect you five times against other exploits? So in the bottom line, was it a good idea to add it, or not? Things are rarely black and white in life.

When you say something terse like "increased attack surface" it completely closes the door on the possibility that Chrome would have an exploit which Sandboxie would protect you against. But since you now seem to acknowledge such possibility, I would ask you to consider losing the bit about "increased attack surface" and just say that your opinion is that you're personally comfortable with using just Chrome, and leave it at that.

[jellybelly]

Would it make much of a difference (protection wise) if I used SRWare Iron instead of Google Chrome with sandboxie? With Iron the user has to download Flash Player.

[D1G1T@L]

what a silly thing to say, like comparing a blacklist to hips or something. Just because you can call them both a sandbox does not mean they're comparable in any way. Sandbox = restrictions, that's it. Chrome and Sandboxie use wildly different methods and I would not call either of the techniques more powerful than the other.

I didn't say they use the same techniques. Unlike HIPS vs AV, your example is incongruent with the Sandbox vs sandbox subject matter of this topic. Their wildly different methods are what makes one provide more protection than the other, I mentioned this numerous times in this thread. It is also the reason why they are compatible, becuase they don't work the same way ie. you can't sandbox another sandbox driver under the first.

Anyone with common sense will tell you that Kernel mode hooking (Sandboxie) is more powerful than usermode (Chrome). Since you say that you have a programming background, you'll know that to be true.

1) Sandboxie could potentially save you from a Chrome exploit (none exist in wild...yet)
2) Sandboxie could potentially introduce more vulnerabilities into Chrome via the .dll (none exist in wild...yet)
3) Sandboxie could potentially conflict with Chrome's built in security, which is not something I'm saying has or will happen.

Balanced summary, but based on theoreticals. Theory has an element of truth in possibility, however that doesn't make it applicable in real life.

Your theory could be extrapolated to the idea that nothing is secure, nothing is unbreakable therefore everything is weak.
In practical daily use, security and encryption is good enough and assumed to be close to perfect unless breached/exploited. Not the other way around.

What I know is the dual setup works good until proven otherwise. The burden of proof regarding this setup being inviable would lie upon you. Saying that Sandboxie makes Chrome insecure is rather abstract and esoteric to the discussion when not backed up by any real evidence of that being the case, especially when you didn't qualify your statement with it being theory. It gives the distorted/innaccurate/even unfair impression that there are many reports of software conflict and harm caused by having them both.

To each their own.

+1

[D1G1T@L]

Would it make much of a difference (protection wise) if I used SRWare Iron instead of Google Chrome with sandboxie? With Iron the user has to download Flash Player.

I would not recommend using SRWare Iron since its development lags far behind. Iron uses outdated versions of Chromium that have usability and seecurity bugs that have already been addressed in its Chrome counterpart. Google Chrome has the most recent patched versions.

The only reason to use Iron is no longer applicable since Google's privacy options have seen substantial improvement since then. Chrome provides flash sandboxing which is better than nothing as the case with Iron. Out of both browsers, Chrome is the better option.

[jellybelly]

Thank's D1G1T@L, good information.

[HungryMan]

Alright guys, let's try to cut down on the negativity here. HungryMan, I can agree with your 1,2,3 points summary, because at last that is a fair and balanced summy . I agree that all software has potential to be exploited. In fact let me quote something I said in another topic.

As for running more or fewer security apps, that's your decision. Clearly every additional piece of software that you introduce to your system adds more security risks. And let's suppose that some security software that you add has an unknown exploit hidden somewhere. What if that expoit is never actually exploited, but that security software does protect you five times against other exploits? So in the bottom line, was it a good idea to add it, or not? Things are rarely black and white in life.

When you say something terse like "increased attack surface" it completely closes the door on the possibility that Chrome would have an exploit which Sandboxie would protect you against. But since you now seem to acknowledge such possibility, I would ask you to consider losing the bit about "increased attack surface" and just say that your opinion is that you're personally comfortable with using just Chrome, and leave it at that.

Yup, I didn't ever mean to say that Chrome was some invulnerable program. I've talked a lot about exploits in Chrome (through extensions and apps) and it would make no sense for me to think any program was flawless.

My point on Wilders was only that I personally think that there are potential issues with both and I prefer the simpler setup. Sandboxie is still the program I trust to secure my computer (and EMET) I just like case-by-case.

@Digital

Anyone with common sense will tell you that Kernel mode hooking (Sandboxie) is more powerful than usermode (Chrome). Since you say that you have a programming background, you'll know that to be true.

I'm not trying to be mean but I don't think you know what this means or you would understand the issues with what you're saying. Again, not in any way meant to insult you or be a jerk.

@JellyBelly

I agree with Digital, 3rd party Chromium builds such as SR IronWare or ChromePlus tend to lag behind Chrome by a full version even. This means you lose out on some performance, stability, and security fixes.

[Lumberjack]

With a simple comparison it should be clear what level of protection each provides separately. No harm combining both.

Chrome

Design principles

Do not re-invent the wheel: It is tempting to extend the OS kernel with a better security model. Don't. Let the operating system apply its security to the objects it controls. On the other hand, it is OK to create application-level objects (abstractions) that have a custom security model.
Principle of least privilege: This should be applied both to the sandboxed code and to the code that controls the sandbox. In other words, the sandbox should work even if the user cannot elevate to super-user.
Assume sandboxed code is malicious code: For threat-modeling purposes, we consider the sandbox compromised (that is, running malicious code) once the execution path reaches past a few early calls in the main() function. In practice, it could happen as soon as the first external input is accepted, or right before the main loop is entered.
Be nimble: Non-malicious code does not try to access resources it cannot obtain. In this case the sandbox should impose near-zero performance impact. It's ok to have performance penalties for exceptional cases when a sensitive resource needs to be touched once in a controlled manner. This is usually the case if the OS security is used properly.
Emulation is not security: Emulation and virtual machine solutions do not by themselves provide security. The sandbox should not rely on code emulation, code translation, or patching to provide security.

Sandbox windows architecture

The Windows sandbox is a user-mode only sandbox. There are no special kernel mode drivers, and the user does not need to be an administrator in order for the sandbox to operate correctly. The sandbox is designed for 32-bit processes and has been tested on Windows 2000, Windows XP 32 bits, and Windows Vista 32 and 64 bits.

Sandbox operates at process-level granularity. Anything that needs to be sandboxed needs to live on a separate process. The minimal sandbox configuration has two processes: one that is a privileged controller known as the broker, and one or more sandboxed processes known as the target. Throughout the documentation and the code these two terms are used with that precise connotation. The sandbox is provided as a static library that must be linked to both the broker and the target executables.


Other caveats
The operating system might have bugs. Of interest are bugs in the Windows API that allow the bypass of the regular security checks. If such a bug exists, malware will be able to bypass the sandbox restrictions and broker policy and possibly compromise the computer. Under Windows, there is no practical way to prevent code in the sandbox from calling a system service.

Sandboxie in contrast, does reinvent the wheel and gives you kernel mode sandboxing which is more robust.


Sandboxie FAQ

How does Sandboxie protect me, technically?

Sandboxie extends the operating system (OS) with sandboxing capabilities by blending into it. Applications can never access hardware such as disk storage directly, they have to ask the OS to do it for them. Since Sandboxie integrates into the OS, it can do what it does without risk of being circumvented.

The following classes of system objects are supervised by Sandboxie: Files, Disk Devices, Registry Keys, Process and Thread objects, Driver objects, and objects used for Inter-process communication: Named Pipes and Mailbox Objects, Events, Mutexs (Mutants in NT speak), Semaphores, Sections and LPC Ports. For some more information on this, see Sandbox Hierarchy.

Sandboxie also takes measures to prevent programs executing inside the sandbox from hijacking non-sandboxed programs and using them as a vehicle to operate outside the sandbox.

Sandboxie also prevents programs executing inside the sandbox from loading drivers directly. It also prevents programs from asking a central system component, known as the Service Control Manager, to load drivers on their behalf. In this way, drivers, and more importantly, rootkits, cannot be installed by a sandboxed program.

Hi, didn't you say that Sandboxie is more robust in security than DefenseWall?
Unfortunately I can't find your post, but I saw it.
Could you answer me via Private Message, since this is not thread about it?
Thanks.

[Scoox]

I deliberately install and run Chrome and also Firefox each in their own separate sandbox, so that when I re-install Windows all my settings are there, all I need to do is install SB and copy sandboxie.ini file installation directory. I do this for many other applications which saves me the painful task of installing and configuring them one by one. This makes OS re-installs a breeze.

[Craig@Invincea]

I deliberately install and run Chrome and also Firefox each in their own separate sandbox, so that when I re-install Windows all my settings are there, all I need to do is install SB and copy sandboxie.ini file installation directory. I do this for many other applications which saves me the painful task of installing and configuring them one by one. This makes OS re-installs a breeze.

Yep. that's a great tip.

As we change things in the GUI, I might recommend having a quick access button to "export" the ini to a file to have for such a scenario.

[Scoox]

Sorry about the sloppy English of my previous post, it was a bit late when I wrote it. What I forgot to mention is that I put my Sandboxie directory on a drive other than the system drive, in other words, my sandboxes are NOT in my c:\sandboxie\ which is the default dir. This can be done by including the following line under [Global] in your sandboxie.ini file:

Code: Select all

[Global]
FileRootPath=Z:\Sandbox\%SANDBOX%

By keeping your sandboxes on a non-system drive, e.g. "D:\Sandboxie", you can re-install Windows at any time knowing that your sandboxes are safe. You can also back them up as part of your regular backup routine, if that's the sort of thing you do.