Advice Request ReHIPS Isolation: Run Chrome in sandbox?

Please provide comments and solutions that are helpful to the author of this topic.

Status
Not open for further replies.

shmu26

Level 85
Thread author
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Jul 3, 2015
8,150
If I have a decent anti-executable, to handle the downloads, is there any reason to run chrome in a sandbox, even though chrome already sandboxes its processes?

I am asking because I saw that by default, ReHIPS runs chrome in isolation, even though ReHIPS has a strong mechanism for blocking all unknown executables.
 

XhenEd

Level 28
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Mar 1, 2014
1,708
That will be a long debate.

In Wilders, from my perspective, that issue is still unsettled. Some would say that Chrome shouldn't be "double-sandboxed" since it is sandboxed already and that doing so might break Chrome's sandbox mechanism, while others would say sandboxing Chrome adds another layer of protection. For now, it depends on one's perspective, until majority of security people come to a consensus as to what's best for a software that is sandbox-built.

I use Chrome within ReHIPS' sandbox, by the way. :D
 
Last edited:

shmu26

Level 85
Thread author
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Jul 3, 2015
8,150
I think you and XhenEd are going for ultra protection.
For ordinary mortals, I think chrome with updates + a good anti-executable + a good anti-exploit should really cover everything, without putting chrome in sandbox.
 

SHvFl

Level 35
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Nov 19, 2014
2,342
I think you and XhenEd are going for ultra protection.
For ordinary mortals, I think chrome with updates + a good anti-executable + a good anti-exploit should really cover everything, without putting chrome in sandbox.
Probably correct but i see 0 downside of using rehips with it so i use that.
 

Azure

Level 28
Verified
Top Poster
Content Creator
Oct 23, 2014
1,712
That will be a long debate.

In Wilders, from my perspective, that issue is still unsettled. Some would say that Chrome shouldn't be "double-sandboxed" since it is sandboxed already and that doing so might break Chrome's sandbox mechanism, while others would say sandboxing Chrome adds another layer of protection. For now, it depends on one's perspective, until majority of security people come to a consensus as to what's best for a software that is sandbox-built.

I use Chrome within ReHIPS' sandbox, by the way. :D
> might

That was the problem. Most of what I read in that thread seem to have been based on hypothetical scenarios. Meaning no one(or the great majority of people) knows without a shadow of a doubt whether it's beneficial or not.

me too :D

my browser protection? ReHIPS' isolation + HMPA + some Chrome tweaks
I know that you use Appcontainer. Does ReHips' sandbox sets Chrome's process to Untrusted like Sandboxie does?
 
Last edited:

SHvFl

Level 35
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Nov 19, 2014
2,342
it's just less convenient, that's all. You can't attach a file to a gmail message by simply dragging it from your desktop, for instance.
You are right there are some inconvenient. Just don't sweat it a lot. Do what you are comfortable with. The chance of getting infected shouldn't change by a lot.

I know that you use Appcontainer. Does ReHips's sandbox sets Chrome's process to Untrusted like Sandboxie does?
Nope. Rehips does something better. It launches chrome as another user with more restriction than sua.

Quoting Fixer that knows a lot more than all of us probably
Elevated admin. Maximum access rights, can read+write from everywhere across file system and registry.
Non-elevated admin=LUA. Slightly restricted read rights (some files may be SYSTEM read-only, but elevated admin can take the ownership and grant any access rights to itself and LUA can't do it, but there are few system locations like this+other users' profile folders and registry hives are also inaccessible) and restricted write rights (restricted for the same reason as reading is restricted, but there are significantly more locations, like Program Files, Windows, System32, etc and HKLM registry hive). But this user is vulnerable to LUA elevation and may become elevated admin.
Non-admin user=SUA. The same as LUA, but without elevation vulnerability for the cost of usability.
ReHIPS User. The same as SUA with further restrictions. If you take a closer look, you'll see that by default write access to most files and folders is granted to Authenticated users. And every logged-in user including LUA, SUA and ReHIPS User are Authenticated. ReHIPS turns this group in isolated programs token into deny-only. So no write access will be granted to them by that access control entry. And on top of that, several more filters are layered: network storages, removable media, CD/DVD/BD disks, unsecured filesystems (that don't support access rights like FAT). Besides SUA provides some kind of isolation to protect OS, but if you run all programs in SUA and keep all documents there, one exploited/rogue application will endanger all of them. And ReHIPS keeps different isolated environments isolated not just from OS and real user, but also from each other meaning for example browser gone haywire won't affect office documents in any way.
In other words, ReHIPS User has read access as SUA. And write access is limited to its profile folder and several folders that are explicitly allowed to write to by Windows (we're currently working on blocking write access there too).
If Copy User Data is checked, read access to the real user profile folder will be granted, it's recommended to use for compatibility purposes only during first start and then disable it.

If any isolated program is exploited, it can look for installed software as it's usually installed in Program Files and read access to it is granted. And even if you allow process creation without any isolation or allow parenting without any child inspection, every child process is subject to inheritance. In terms of security pretty much everything is inherited: token, access rights to any objects, including file system and registry, privileges, integrity level, etc. It means that any child process won't be able to escape isolation if parent process was isolated. And it's not just process creation, any action won't allow isolation escape, including task scheduling, some .NET modules registration, unusual host processes usage or some other stuff that is now popular to bypass other security software. Otherwise it's Windows vulnerability and will be patched by MS.
 

Cch123

Level 7
Verified
May 6, 2014
335
ReHIPS sandbox with Chrome is probably fine since ReHIPS uses Windows' own mechanisms for sandboxing, just like chrome itself. However, doing so might not necessarily provide additional protections since ReHIPS seem to share many of the sandboxing techniques already implemented in Chrome.
 

FleischmannTV

Level 7
Verified
Honorary Member
Well-known
Jun 12, 2014
314
I don't think it is necessary, but I'd rather protect Chrome with either Alert or reHIPS, because it's not taking two steps back and 1.99 forward like Sandboxie does it (in Chrome's case only). reHIPS is much more elegant in that regard and doesn't mess with Chrome.

Though personally, I'd use neither.
 
D

Deleted member 178

I know that you use Appcontainer. Does ReHips' sandbox sets Chrome's process to Untrusted like Sandboxie does?

In term of integrity level, ReHIPS does as Sandboxie ; set on Untrusted, anyway at the moment no isolation software can give Appcontainer level, for this they must be redesigned entirely.
 
H

hjlbx

Chrome's built-in sandbox isolates open tabs from each other and from parts of system - I believe direct disk access, registry and file system; ReHIPS isolates Chrome from the real user file system and registry.

Chrome employs a user-mode sandbox.

ReHIPS does not use a virtual sandbox - it is not like Sandboxie in terms of a virtual container; it uses a user profile sandbox and does not involve virtualization - it restricts a processes privileges as @Umbra points out.

Running Chrome isolated - I would think there would be no breakage whatsoever - since the isolation mechanisms don't appear to interfere with each other.

Plus, I am not sure if any Chrome add-ons run inside the Chrome sandbox - if they don't then it would make sense to run Chrome in the ReHIPS isolated environment.

You'd have to ask @FleischmannTV on the exact Chrome sandbox details - as I don't use Chrome and have not looked into its sandboxing in-depth.

If ReHIPS hobbled Chrome's own internal security mechanisms in any way, I would think ReCrypt staff would not allow Chrome to run isolated.
 
Last edited by a moderator:

SHvFl

Level 35
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Nov 19, 2014
2,342
A tweak allows all plug-ins to be sandboxed,not sure if it include extensions.
Yeah everything runs in appcontainer with the tweak. Except parent in medium and another in low.
Also you can do the Win32k lockdown sandbox policy now with a flags edit, same way you do the appcontainer.
glTibfn.png
 

FleischmannTV

Level 7
Verified
Honorary Member
Well-known
Jun 12, 2014
314
Addons and plugins are already sandboxed. Chrome no longer supports unsandboxed plugins since some time ago. The tweak @Umbra mentioned is an additional system call filter for plugins (only availabe on Win 8.1 and newer). Filtering system calls is an important function to prevent sandbox escapes.
 
Last edited:
H

hjlbx

A tweak allows all plug-ins to be sandboxed,not sure if it include extensions.

Thanks bro... I wasn't sure.

In a nutshell, I think ReCrypt would not allow Chrome to run isolated if somehow ReHIPS isolation would interfere or break Chrome's built-in protections.

Anyone that knows ReCrypt staff knows that they just wouldn't allow it.

To me, Chrome + ReHIPS = double or dual-layered protection.
 
Status
Not open for further replies.

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top