Is there a conflict with sandboxie?

[nick]

I have sandboxie on my system and now that I try to use it in combination with ReHIPS there seems not to be compatible. I want to allow sandboxed programs (under sandboxie) but although I try to allow them when ReHIPS asks me the sandboxed programs never start. Actually the processes start (I can see them running at process explorer) but I cannot see anything on my screen. Does this has something to do with the anonymous user that sandboxie puts as the owner of the processes instead of my normal account ? Is there anyway around it?

[fixer]

There recently indeed was a report about sandboxie and my reply to it here https://forum.rehips.com/index.php?topic=13400.msg22539#msg22539 In short words, there was some issue with sandboxie and ReHIPS was just provoking it. So maybe this is it.

[nick]

At what step does ReHIPS decides to display an application in a different desktop? Sandboxed processes are owned by an anonymous user, there is no ReHIPS rules database for such a user. A process with such an owner how is it interpreted by ReHIPS, as an isolated environment that needs a separated desktop to be in?

[fixer]

ReHIPS isolated processes can be started on a separate desktop, it can be enabled/disabled on a per-isolated environment basis in isolated environment options.
There is definitely no need to try to both isolate a program in ReHIPS and sandbox it in Sandboxie at the same time. So just Allow them in ReHIPS (and it won't interfere) and sandbox them in Sandboxie or isolate in ReHIPS and ignore Sandboxie.

[nick]

No the problem is exactly the same like in the post you mentioned, at least with thunderbird and waterfox. No isolation ReHIPS regarding, but when I try to open them sandboxed, the processes start but never display on the screen. I just thought it might had to do with how ReHIPS handles processes (and child processes of them) belonging to unknown untrusted users that's why I asked

(It is similar as when  ReHIPS opens an alert window waiting for a respond. What if a child process of them is not in ReHIPS list yet, will the alert window open in the current user desktop even though the process is owned by a different unkown user?)

[fixer]

No, if a process is allowed, ReHIPS lets it execute as is and doesn't impose any limitations.

Alert window is always opened on the same desktop the main ReHIPS Control Center is opened on. It doesn't depend on desktop of the program the alert is notifying about or on the user the program is executed from.

[Umbra]

i tested both together by curiosity long time ago, i saw this conflict.
Anyway i don't see the point of isolating the same program with 2 sandboxes at same time, not saying Sandboxie is abandoned, not worth wastin g time on it while ReHIPS is obviously superior.

[nick]

Thanks fixer for the respond, was just a thought.

Thank you Umbra, actually I was not isolating those with ReHIPS, just they are not be displayed while ReHIPS processes are running. Rehips is definitely more active and the better alternative to sandboxie with as far as I understand more broad securtity features and that's why is my choice for a switch when sandboxie will be fully not functional. For the time I try to use them synchronously, sandboxie virtualization offers some features I'm used to that do not (I think) exist in ReHIPS, specifically the fact that a sandboxed program does not make any changes out of its sandbox

[Umbra]

specifically the fact that a sandboxed program does not make any changes out of its sandbox

so do ReHIPS, i dont see how a sandboxed program can change something outside the Isolated Environment (unless you allow it via the settings), it would defeat ReHIPS purpose.
Sandboxie uses a single container where all the sandboxes you created are grouped.
ReHIPS also has a container but its isolation is made via hardened user profiles (those are the "sandboxes"); maybe it is what you meant by "changes outside its sandbox"

maybe you can give us an example.

[nick]

Sorry for the so delayed respond but it was a busy period with deadlines for me, no time to spend trying ReHips.

I didn't mean it like that, what I meant is that there are programs that require access to specific locations/to specific installation path and also make changes to registry. In the virtual environment approach as it is implement at least on sandboxie you don't have to worry about that, program understands that everything is done as required but everything is in the virtual environment, do not change something to the system and very easily removed. With effort that can be done for files and folders on ReHips too but it is not trivial or clear. As far as it evolves registry I'm not sure what happens and actually that is a question:
Following this https://forum.rehips.com/index.php?topic=9560.0 seems to imply that there is a virtualization of registry? I understand that if there is an attempt to entry a new value that will not be accepted? What about modify, what is the relation with the Registry keys access rights that you give for that isolated environment?

[fixer]

Welcome back, nick

Basically ReHIPS isolates in the following way. For every isolated program it creates a custom restricted Windows user called ReHIPSUser. Each time this program is started it's started from this restricted user. By Windows security model other users (ReHIPSUser in our case) can't access private data (files, folders, registry, etc.) or affect programs of other users (other ReHIPSUser-s or real user, the one you use). And because it's a simple user (not Admin) it can neither affect the System. This is the first level and basic level of isolation. Some other levels are also in place, but they mostly tighten this concept than bring something drastically new.

So basically no, isolated programs don't have virtualized registry. They have their own registry hive and simply can't access real user registry hive or write to system parts of the registry. And the same goes for file system objects.

[nick]

Thanks fixer But there are advanced settings that allow us to customize some privileges right? On your post about Copy user data feature you mention registry keys values and also there is the registry access settings (also in the isolated environment settings window). Does it only evolve keys in the ReHips profile hive? What happens if an isolated program requires admin rights, is there a way to provide them in a controlled customized way (file access can be done from the relative settings, what about global settings (for all users/registry keys))?

[fixer]

I described basic restrictions applied by default. If you want, you can weaken them. For example allow any access to system registry or files. Access to real-user registry hive and profile folder will be denied anyway, but with Copy User Data it's possible to copy required data to ReHIPSUser registry hive/profile folder.

If a program requires admin rights (and I mean it really needs them and not just asks because developer copy-pasted this code just in case), then there is no safe way to run this program. If you really need it and don't trust it, consider using some VM like VMWare or VBox.

[nick]

It's not necessarily about a malware but could be security weak/stop developed so eventually might open security holes in the system. As long as I am able to control what changes ara done and where, I can be ok with that. What I would prefer to exist as a feature is a way to be able to revoke them. As I mentioned above (because of files' owner difference), it's doable for files, although not trivial and perhaps not guaranteed without advanced skills, but it's not possible for registry changes. A log for those and a way to revoke them by deletion of an isolated environment would be nice (and that is the difference I was referring above with sandboxie)

[fixer]

In ReHIPS it's possible to allow or block access to registry keys or file system objects (files and folders). But logging is quite complicated. You see, Sandboxie is built on hooking and proxying calls. A lot of hooking actually. And this concept has its advantages and drawbacks. For example it has performance penalty. But since it proxies each and every call it can log access attempts quite freely. ReHIPS on the other hand doesn't control access itself, it relies on Windows already implemented security checks, so ReHIPS isn't involved when a program tries to access something, ReHIPS can be even disabled, when it happens, Windows does all the heavy-lifting. As a drawback there is no simple way to log these access attempts. Well, there can something be done actually, logging access to some certain objects in possible via Windows audit system. But it isn't useful when it comes to a situtation like "this program wants something, but I don't know what".