Thx @wat0114 I am not native speaking English, so something might get lost in translation. Most important is that the forum member posting the question did understand my answer. Special short version for @CoolWebSearch Appcontainer versus Untrusted + Sbie default probably Appcontainer safer Appcontainer versus Untrusted + Sbie tight configured sandbox limiting file acces and internet with Chrome switch win32-lockdown probably equally safe But feel free to post test prooving differently and or analysis of say 80% (the top 20 most used) malwares versus the reverse engineered kernel filters of Sbie. Since I don't have that data, I can only say 'probably'
Another Chrome sandbox escape was found: http://googlechromereleases.blogspot.nl/2016/02/stable-channel-update_18.html
Well these Chrome sandbox bypasses are sure piling up Excluding this latest one, CVE has on record a whopping four of them with 10.0 scores since 2008. Seriously, I'd be far more concerned about plugins - especially anything Adobe related - as well as goofy extensions, than I would about the browser, and that includes any browser for that matter.
One thing I cannot understand, Chrome locks win32k permanently-Sandboxie cannot do that-Sandboxie cannot block win32k, so how exactly they are equal?
...Running under SBIE won't somehow make Chrome not lockdown win32k Oh and is AppContainer for Chrome still broken on Windows 10?
I know that, but the fact is I do not understand how can anyone claim that Chrome lock down of win32k is equal to Sandboxie protecting win32k, it doesn't make any sense.
At least metro mode is broken. Is there another implementation of AppContainer that I forgot or missed? Chrome lockdown of win32k + SBIE hardened is about equal to AppContainer. That is what he meant.
yes. From chrome v48+ , by typing chrome://flags (and enabling the option), you can run Chrome directly in AppContainer without being in metro mode. http://i.imgur.com/Wu2v4yZ.png then chrome integrity will show: http://i.imgur.com/vjXc5Iz.png as you ca see, some processes aren't in AppContainer, i guess one of them is the broker. note that using sandboxie will gives Chrome lower integrity (untrusted) , however ALL processes will be at untrusted.
Ah, that's what I forgot. Skimmed the thread, but too much of the same stuff masked the answer. At least I believe this was mentioned already before.
yep it was mentioned but at that time Chrome stable wasn't at v48 , until that the option wasn't available.
I still don't understand, as far as I know AppContainer actually locks kernel, Sandboxie does not do that-and what about parts of windows and files and folders and exes, dlls and etc that Sandboxie cannot block and can never block in the first place-heck, AppContainer can do that, but Sandboxie cannot do that-this is where the key distinction is. It heavily depends what exactly AppContainer can block/lock compared to Sandboxie and how much, which approach can block/lock more of the kernel and everything else for that matter. Do you understand what I mean?
AppContainer goes deeper than Sandboxie (which is at "untrusted" integrity), however Sbie can protect more things that AppContainer (AC is limited to Metro apps or apps designed to use it, if not most apps run at medium integrity level as a base ). all depends of what the user want : - running few apps at the safest integrity level possible = AppContainer - running almost any apps at a safe integrity level (Untrusted) = Sandboxie Now as i said before, for Chrome , there is a dilemma (if you apply the tweak mentioned earlier) : - should you run Chrome + sandboxie = ALL chrome's processes only as untrusted, but you can tweak Sbie very tightly. or - should you run Chrome alone = ALMOST all processes run in AppContainer.
Exactly, thx So Sbie users just have to add the win32 -lockdown switch as parameter for Chrome and you have similar attack surface reduction to kernel as AppContainer (although Chrome processes run as untrusted under Sbie) This win32-lockdown is not a Sbie feature, but a Chrome command switch which works independently from the AppContainer flags option.
Yes these type of sandbox escapes without the use of kernel exploits are very rare. But still interesting to see that it's possible, and keep in mind who knows how many zero days exist for Chrome and other browsers. So it's always a good idea to protect Chrome.
Interesting. I'm wondering something. If you use process explorer to check, chrome + tweak = processes appear as appcontainer. I got that. But when you say Sandboxie + chrome + tweak = untrusted. Did you meant that process explorer will see the processes as untrusted regardless of the tweak or that it will say "appcontainer" but in reality the integrity is still untrusted?
Agreed. Even though I'm running Chromium on Linux, I still sandbox it with firejail, as well as use uBlocko extension to guard against malicious 3rd party scripts and frames + blocking ads, also https everywhere extension, click-to-play plugins. Under the circumstances this is probably ridiculous overkill, especially considering how strong the Chromium sandboxing already is under Linux (uses Seccomp-BPF sandbox), but since it doesn't do anything to noticeably affect performance or stability, I figure: "what the heck"...might as well use the extra reinforcements. Make no mistake about, though, if there were stability and/or performance issues with this setup, I'd remove whatever necessary to remedy the issues.
Sbie+ chrome + tweak = All chrome processes being reduced and shown in PE as Untrusted; because it is the maximum integrity level Sbie can handle, Sbie can't handle the Lowbox Token made to create AppContainer.
Thanks for the reply. I was checking with process explorer, and even with Comodo sandbox it still showed Chrome integrity as AppContainer.
Just wondering-why can't Sbie handle Lowbox Token made to create AppContainer? Did anyone from Invincea actually confirmed that?
I was just wondering how much you can configure Comodo's sandbox in order to block everything you want to be blocked, and what about integrity level-is it untrusted as Sandboxie-how tightly configured in order to block everything than can be blocked Comodo's sandbox can achieve so far, the same as Sandboxie or not? What are their differences-to be honest the reason why I never tried Comodo on windows 10 x64 bit is because I'm so scared of Comodo's bugs, which I why I use Sandboxie over and on all web-browsers that I use (IE11, Firefox, Chrome, of course the only web-browser that cannot be sandboxed is Microsoft Edge, which is the same as Google Chrome when it comes to security and protection) all the time. I also have separated sandbox for entire Windows Explorer-where everything is allowed to run, but also everything is blocked to access internet. Cheers.
Just for the record, I do use Sandboxie all the time on my Windows 10 x64 bit, tightly configured according to my needs, despite my posts criticize or ask questions about Sandboxie's security, protection and integrity levels. Yes, I do the same with all web-browsers inside Sandboxie.
