IE8 does sometimes put multiple tabs in one process, but not all tabs are in the same process. I think Microsoft should move to one-process-per-tab too;
The problem is that all these processes run in the same sandbox (at the integrity level "Low"), so they are not protected from each other.
But, I'm not sure the rest of what Chrome does would be useful in IE
Again, like IE, Chrome itself uses OS mechanisms for the sandboxing.
In particular, one thing that's strange about NaCL is that plugin processes have stronger security than Chrome itself
This differentiation seems reasonable because Chrome itself is considered trusted code, whereas these plugins aren't.
I would still like to know, theoretically, what Chrome's design stops that cannot be stopped using IE8's design, modified to have one tab per process.
Since IE has one sandbox for all processes, one compromised tab could affect other tabs. Not so in Chrome.
If IE switched to one process per tab and one sandbox per process, things would be more similar, but NACL in a Chrome sandbox would still be more secure than ActiveX in an IE
sandbox because of NACL's additional layer of security. A NACL plugin would need to exploit weaknesses in both NACL and the Chrome sandbox in order to do any damage.
Chrome's sandboxing is conceptually more secure than IE's, and NACL is more secure than sandboxed ActiveX. The key difference in both cases is granularity.
Chrome sandboxes each tab individually, whereas IE runs all tabs in the same sandbox. It's true that in both cases a malicious website could not cause much damage to the OS, but as more stuff moves into the browser it becomes more important that a malicious web app cannot mess with other web apps (tabs) that are open.
If a malicious website gains control over the IE sandbox, it has access to all web sessions within the sandbox. This is not true for Chrome.
Chrome, like IE, uses OS mechanisms for its sandboxing on Windows, most importantly restricted tokens. These have been around since Windows 2000 and are more powerful than the one dimensional integrity level introduced with Vista.
NACL is two steps ahead of ActiveX with regards to security. An ActiveX control running in the IE sandbox has immediate access to the whole sandbox (which includes all running tabs). Because of this, one would never run an untrusted ActiveX control, period. Hence the prompts and signature checks.
NACL on the other hand has two layers of defense, and each one would conceptually be sufficient to run untrusted content. The first layer is the native client sandbox (with the verified machine code etc.). The second layer is the per-tab Chrome sandbox described above. So even if a native client app breaks out of the native client sandbox, it would then have to break out of its tab's Chrome sandbox to do any damage at all.
Sorry about this confusion, such messages can be worrying, but let me assure you that BaseShield is not doing anything malicious here. Symantec Endpoint Security is reporting some activity that is in fact happening but is not malicious. To achieve its high level of sandbox security, BaseShield in some cases loads dlls into other processes.
This is a common technique that is natively supported by the Windows API and is in itself perfectly safe. We will investigate how this can be avoided and try to make sure BaseShield does not trigger these warnings with this product.
Again, apologies for the inconvenience. Please contact me directly at sascha (at) baseshield.com if you have any questions about this.
UPDATE:
Symantec Endpoint Protection appears to be prone to showing false alerts. This not only affects BaseShield but also other products, including Microsoft Virtual PC.
You're absolutely right, no fundamental reason why it wouldn't work. It's mainly that some components need to be re-compiled for 64bit with some adjustments for Wow64. It's high up on the list of things to get done.
At the moment you have to go to an app's page and if there's an update you can get it with one click. There's a lot of potential for further automation.
This installer makes it as easy as possible to install the product without asking the user to make unnecessary decisions. The reasoning is that the few users who don't want a desktop icon are likely to be advanced users like you who can easily delete the icon.
Regarding installation in the Windows directory, flash also does this (C:\WINDOWS\system32\Macromed\Flash). For BaseShield there are technical reasons why some components need to be below the system32 directory.
Please use the one click uninstall to remove downloaded applications before uninstalling BaseShield. We need to make this more clear or automatic, sorry.
Feel free to contact me directly at sascha (at) baseshield.com with any technical issues.
The main difference is BaseShield's secure virtualization. It's true that there are other platforms that make downloads convenient, but none of them can automatically enforce certain behavior for the applications.
The virtualization layer only supports user mode applications; kernel mode drivers unfortunately won't work. Services are not yet supported but support may be added in the future.
Thanks for your comments! (I'm one of the founders)
It works for application packages that are in the repository. Right now we have a collection of free software but we want to encourage developers to sign up and offer their apps through the store. We'll make the whole repository browseable soon so you can see what's
in the store right away. We're also working on improving the design.
Interesting, but "cracked" may be a bit strong. It only works if the attacker has already gained access to the process through some other vulnerability.
Also full trust vs app container here: https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop...