Advice Request ReHIPS Isolation: Run Chrome in sandbox?

[SHvFl]

I have no issues running Chrome isolated in ReHIPS unlike with Sandboxie (which trigger some error alerts); i guess when ReHIPS will be stable i wont need Sbie anymore.

What i hated with sandboxie was the constant updates and things breaking. I get mad when i have to update something again and again for stupid reasons. I already ditched sandboxie and never looked back.

 

[_CyberGhosT_]

@SHvFl
It would have made a nice litter box, what ? lol

 

[Deleted member 178]

What i hated with sandboxie was the constant updates and things breaking. I get mad when i have to update something again and again for stupid reasons. I already ditched sandboxie and never looked back.

i'm really tempted to do so for the same reasons.

 

[SHvFl]

i'm really tempted to do so for the same reasons.

Do it. Talked to Gaben and he agreed. Except if you need folder virtualization which in that case unfortunately you need to wait.

 

[Deleted member 178]

Except if you need folder virtualization which in that case unfortunately you need to wait.

i have Securefolder that block execution of executables in folders.

 

[shmu26]

this is an old thread but I wanted to add the insight I had today: if you use ReHIPS as intended, which means that all vulnerable apps are isolated by default, it creates a fool-proof environment.
It doesn't matter anymore if the user makes all the wrong decisions and gets infected, because the isolated environment is a disposable one. So no damage done.
This is different from a standard default/deny solution, which depends on the user making the right decisions.

 

[509322]

this is an old thread but I wanted to add the insight I had today: if you use ReHIPS as intended, which means that all vulnerable apps are isolated by default, it creates a fool-proof environment.
It doesn't matter anymore if the user makes all the wrong decisions and gets infected, because the isolated environment is a disposable one. So no damage done.
This is different from a standard default/deny solution, which depends on the user making the right decisions.

In default-deny, what is not allowed is blocked. There is very little, if any, decision-making required of the user once default-deny is enabled.

All that default-deny requires of a user is to start with a verified clean system, install base-line software using verified safe\clean installers, and then enable system protection (default-deny\lock down).

Technically, everyone should follow the above procedure no matter what security solution they employ, but very few do.

* * * * *

Actually, the HIPS module of ReHIPS is default-deny with user input required. If some process without an existing allow rule attempts to launch inside an isolated environment, then ReHIPS will generate a HIPS alert outside the isolated environment. They user will have to switch to the desktop and respond (make a decision) to the HIPS alert (Allow or Block).

I recently requested fixer to consider implementing a user opt-in setting to disable HIPS alerts for any processes running in an isolated environment. The isolated environment is quite safe (user-dependent) without those alerts. Last time I checked he is considering it.

The ReHIPS isolated environment is not completely fool-proof. Ask fixer and he will be forthright about the potential risks.

The ReHIPS isolated environment risks (the first one on the list is probably the most relevant day-to-day):

• Whatever is running in the isolated environment has access to whatever data is input into that isolated user profile (user-dependent)
• Inter-process communication if an isolated environment is configured to allow multiple programs to run in it (user-dependent)
• Set Windows hooks (user-dependent)
• Operating System vulnerability

With the way that ReHIPS is designed and works, all the risk numbers are small. In my estimation very small indeed.

Plus, like you said, the user has the option of deleting an infected isolated environment.

Don't confuse physical system protection with data protection. While they are typically connected, at the same time they are also not the same.

 

[shmu26]

--

 

[509322]

with default deny, let's say I am a stubborn and stupid user (or maybe I'm just having a bad day), and I insist on opening what looks to me like a very fine PDF file. Even though I get a prompt, or an out-and-out deny, I think I know better, so I run the file anyway.
Turns out it is ransomware. With default deny, the system is infected.

No one can idiot-proof a security software.

No security software can protect a user from themselves.

I agree, virtualization, rollback or separate user profiles are much more forgiving in such cases.

It is precisely because of such behavior that a user should be locked-out of the system, thereby preventing them from shooting themselves in the foot. That's the whole premise of software restriction policy; the home user can lock their system and disable that lock when they so choose whereas in Enterprise the user pretty much completely locked out and only the Admin can unlock the workstation.

A lot of people bemoan the fact that security or related software X protections fail in this instance or that instance, but when presented with a surefire means of protecting the system they don't use it because it requires a little bit of effort and discipline on their part - even when that effort and discipline are anything but difficult.

So, for those users who know better, but instead choose to do the wrong thing for whatever reasons get exactly what they need - a nasty lesson.

 

[shmu26]

No one can idiot-proof a security software.

No one can protect a user from themselves.

I agree, virtualization or separate user profiles are much more forgiving in such cases.

true, and actually, I deleted my post, because I realized that I made an error in thinking.
In the example I gave, the rogue "PDF" file is probably in reality an .exe file or a .js file -- so it would not open in isolation. My example would hold true only if it was a PDF file with embedded code that tries to exploit a vulnerability in Adobe Reader etc, and that is a much rarer case.

 

[509322]

true, and actually, I deleted my post, because I realized that I made an error in thinking.
In the example I gave, the rogue "PDF" file is probably in reality an .exe file or a .js file -- so it would not open in isolation. My example would hold true only if it was a PDF file with embedded code that tries to exploit a vulnerability in Adobe Reader etc, and that is a much rarer case.

Even if an unknown file will open isolated (e.g. right-click > Run in ReHIPS Isolated), it can write to the real user profile (real system) when launched from the desktop (User Space).

Whatever it writes to the file system is inactive, unless the user navigates to the inactive files and executes them.

You can ask fixer about this.

 

[HarborFront]

Hi

What's the difference between HMPA protecting a browser and ReHIPs sandboxing a browser?

Thanks

 

[shmu26]

Hi

What's the difference between HMPA protecting a browser and ReHIPs sandboxing a browser?

Thanks

ReHIPS keeps the browser out of your system, thus preventing any possibility of system infection or exploit, but allows the browser free reign inside its particular ReHIPS user space.

HMPA does the best it can to prevent exploits

You can use both.

 

[_CyberGhosT_]

No one can idiot-proof a security software.

No security software can protect a user from themselves.

You said it Jeff

 

[SHvFl]

ReHIPS keeps the browser out of your system, thus preventing any possibility of system infection or exploit, but allows the browser free reign inside its particular ReHIPS user space.

HMPA does the best it can to prevent exploits

You can use both.

Exactly this but remember if you use both you need to add rehips in HMPA exception list or else it will not function.