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.
