Privilege Elevation and Application Restrictions - Usage Considerations

Privilege Elevation and Application Restrictions - Usage Considerations

These two modules are very much related and there are some considerations to keep in mind when using either one.

Consider the following factors:

1. A single Application Restrictions "ALLOW" rule causes ProfileUnity to go into "DENY ALL" mode and only allow applications to run that are explicitly allowed - similar to the behavior of AppLocker.
2. When a rule in either module is set to use "Hash" as the match method, ProfileUnity must begin hashing ALL starting executables to see whether or not they match - again, similar to AppLocker. Avoid the overhead by not using any Hash rules.
3. When attempting to elevate a FlexApp application, you may need to confirm the EXE's true path by checking taskmgr.exe, Details tab and adding in the Command Line column. Its possible the application shows its path as something like "C:\FADIA-T\...Program Files (x86)\..." instead of just "C:\Program Files (x86)\...".
4. AppLocker and the Application Restrictions module do not play well together. Use one or the other, never both.
5. There is only one factor that determines whether or not a child process of a parent that was elevated by ProfileUnity will also be elevated - that is the presence of a "File->Open" dialog in the parent process. If ProfileUnity detects the parent process window has a File->Open dialog, the child processes will NOT be elevated. This is to prevent a user from using an elevated process's File->Open dialog to launch cmd.exe in an elevated state. If the parent doesn't have this dialog, then the child processes will be elevated as well.
6. Some applications do not "like" the method in which ProfileUnity elevates processes. This is done by detecting a new process, finding a rule match to elevate, killing the process near-instantly and respawning it in an elevated state as the launching user. A workaround can often be found in these situations.
7. The rules in these modules apply when the ProfileUnity configuration is executed. They remain in-effect between reboots, until other rules overwrite them via a change in the ProfileUnity configuration or until the VDI is refreshed back to its "clean state".
8. Elevation rules are machine-wide but Application Restrictions are user-specific.

If elevation is a security concern in your environment but you still have apps that only work in that state, investigate other solutions:

1. Is it just a file/folder permissions issue? Maybe the app needs write access to a config that lives in Program Files? Procmon can help identify the issue. You might choose to modify the permissions for the file/folder to a group allowed to use the application. If its a FlexApp, you could use a post-activation script within the package to correct something that needs elevation to fix, then allowing the app to run un-elevated.
2. Is it a device access issue? Are there permissions that can be changed on the device or driver to allow non-elevated processes access to the device? Again, procmon can help here, as well.
3. Is it a registry access issue? Procmon can help identify, then you can use some of the above info to determine the best way to adjust those permissions, as well.