1 I haven't heard about any plans for ReHIPS changing the GUI. But if you have some good ideas for the dev, get on his forum and tell him. He is very helpful. 2 We can call Shadow Defender light virtualization, but as far as this discussion is concerned, I don't think this affects the integrity level of Chrome processes.
When I tried Comodo sandbox there was a difference between it and sandboxie. I used process explorer to check the integrity of the Chrome processes. When you enable the appcontainer flag, this proceses change from untrusted to appcontainer. However if you use Sandboxie in Chrome, the processes are registered as untrusted integrity. But if you use Comodo Sandbox in Chrome, they stay as appcontainer integrity. This was quite some time ago. So, I don't know if it applies now since I haven't used Comodo Firewall in a long time. What is clear at the time is that there was a difference between Comodo's Sandbox and Sandboxie.
I believe that this is a current bug with Process Hacker at the moment. With the Untrusted chrome.exe processes, you used to be able to check on the Token tab and see AppContainer there as well but that is a recent bug with PH. You can try Process Explorer to confirm the appropriate AppContainer just to ensure everything is working correctly until Process Hacker devs fix this problem.
Ah, yes you're right! I can see that in Process Explorer. (If I run Chrome unsandboxed) BTW, Is there a way to see Mitigation Policies in Process Explorer? In Properties I only see three, DEP ASLP and CF guard. Oh you're right! I couldn't see it in Process Hacker. A clear difference. Thanks, but I already forgot too much about the issues and don't want to reinstall it again. xD oops I don't know Shadow Defender ------------------------------------ What Mitigation policies does "AppContainer" have on your machines? (Or chrome, generally) Do they even play a role when I use Kaspersky instead of WD?
If running Chrome in Windows 10 and Appcontainer isolation enabled, I see no point in running it under a 3rd-party sandboxing program.
But is that a different issue than what this whole thread is talking about? I mean: AppContainer sound like it is chromes sandbox, but even if they are not enabled chrome still has a sandbox?
The thread is about whether or not one runs Chrome in a sandbox. I believe Appcontainer enhances the sandbox over and above the sandbox that runs the browsing renderers at "untrusted" Integrity level.
I don't think you can even run Chrome in Sandboxie with AC enabled. I'm fairly certain it breaks the AC part.
As far as I understand, Process Explorer only shows a few of the MitigationOptions that are applied. Process Hacker is much more thorough in that regard. Personally, I always prefer to use Process Hacker nightly builds.
Right after I got to know about it I preferred it too. But, can I believe what it says about the processes, especially the mitigation policies, when it can't read the Integrity correctly? I'm unsure about that.
Yes, I trust Process Hacker 100%. Approximately 2-3 weeks ago, the Nightly builds of PH were showing AppContainer correctly. Although it was showing on the Token tab but there is currently a bug just within those past 2-3 weeks where it has not been showing. PH has always showed Integrity column for chrome.exe as Untrusted though because it is correct still. The chrome.exe renderer processes are indeed running as Untrusted integrity and within AppContainer sandbox. It is both. I would suggest you could also check out Google's "sandbox-attacksurface-analysis-tools" (https://github.com/google/sandbox-attacksurface-analysis-tools/releases) which are coded by Chrome's sandbox wizard James Forshaw. Download the latest package, extract, and run TokenViewer.exe. On the Processes tab, you can see columns for both Integrity (showing Untrusted) and AppContainer (True) for the chrome.exe renderer processes. But also so much more; it's a great tool and shows quite a bit of information about processes.
Oh that's cool, I'll try that. ... *trying* ... Interesting... Some Windows processes run in an AppContainer. Until now I thought it was Chrome-exclusive. (un-sensibly though) Running Chrome in Sandboxie: It also shows like three times as many chrome processes as the other process managers, with seven running as Medium and one as Medium restricted. (Still in sandbox) Outside of sandbox it shows about 50% of chrome processes in AppContainer (All "restricted"), and half of the other 50% are running with Medium integrity. (About 2 to 3 times as much as in Sandboxie) This just looks like a 50/50 chance of "security-reduction" by NOT using sandboxie. Where the chance is defined by: I just don't know anymore
Because Sandboxie's deepest Integrity Level is untrusted, Sbie can't run at Appcontainer level. No sandboxes can. even Chrome's Appcontainer isn't as tight as those in Metro Apps which relies on "capabilities" , to get true Appcontainer, one soft must be designed as Metro App.
Keep in mind the Appcontainer processes are the renderer or target processes running in the more secure isolation. The broker processes are running at a higher IL. The more restrictive renderer processes can essentially do no more than read at the higher medium broker process but not write to it. This separation restricts the ability of malware to infect the O/S. BTW, running Chrome under a 3rd-party sandbox could potentially - if not probably - introduce new attack vectors. Try to utilize what's already built into Windows for your security rather than layering on 3rd-party software. The latter typically is buggy and, although it may help bolster security, it will likely increase the overall attack vector. Try to embrace the mindset: "less is more".
by design, Appcontainer was created specifically for Metro Apps ( or more precisely Metro Apps are built around Appcontainer). Chrome use many windows security elements, so it can "mimic" Appcontainer IL.