If (and only if) items #1 through #3 (a, b and c) from Fixing LUA bugs, Part I don’t allow your apps to work as normal user, then – and only then – move on to items #4 and #5, which are described in this article, along with their respective benefits and drawbacks.
#4: Loosen ACLs
The usual reason for LUA bugs is that the developers (and often, the testers) always ran as admin. They didn’t explicitly set out to require that the end-user run as admin, but things crept into the code that depended on admin access, such as writing to files in the root folder of the C: drive, in the app’s installation folder under %ProgramFiles%, or in %windir%. The app worked correctly until you ran it on your machine as a regular User. The app wasn’t designed to handle that scenario gracefully, and barfed. (See What is a LUA Bug…).
Option #4 is to change the Access Control List (ACL) on objects to grant your User the access that the program requires. Typically the objects that need tweaking will be in the registry or in the file system (if using NTFS). This must be done very carefully, though, and only after all of the more-preferred options have failed.
Benefits of this approach:
Big return on the investment of your time – most of the LUA bugs that my colleagues and I have seen revolve around file and registry permissions. This approach will probably fix a larger share of your LUA bugs than any other approach.
Drawbacks to this approach:
#5: Run the one app with elevated privileges
As a last resort, after all else fails, consider running that one app with elevated groups and/or privileges. Some apps, for example, “address” their LUA bugs by explicitly checking for admin group membership on startup and displaying an error message insisting that you simply have to be an admin to use the program. This may be due to developer laziness, incompetence or arrogance (or all three), but these apps will be resistant to any other workarounds available to you.
Typically, this approach means running the app as admin. You could instead run the app elevated but less-than-full-admin – for example, as a member of Power Users or with a specific privilege such as SeLoadDriverPrivilege. Note, though, that with a little more work many of these other groups and privileges can still be used to take over an entire system.
It’s better than always running everything as admin. That’s it – that is the only benefit of this approach.
Drawbacks of this approach:
Running an app with elevated privileges exposes far more risk than any of the options described earlier. It becomes very difficult to defend the system against a malicious user or malicious software when there’s an app running as admin. A simple example: Run “Notepad” as admin, then choose File/Open – that dialog is now a little Explorer-like window that gives you full, admin-level access to the entire file system, and even the ability to launch programs as admin. That can be exploited by a malicious user, or by malware pumping keystrokes or window messages into the elevated program.
How to do it:
If you trust the user with the admin password or to otherwise make security and trust decisions:
If you don’t trust the user with the admin password:
Trying to "hide" the admin password:
The DesktopStandard and Winternals products determine in kernel-mode code whether, when and how to modify a process token. Passwords are not used and are therefore not at risk to exposure, and the modification decision cannot be interfered with by non-admins. By contrast, there are various tools available that perform RunAs-like operations with the admin account credentials encrypted (or sometimes just obfuscated). Even though this raises the bar and will stop some users from getting the admin creds, those passwords still have to be decrypted within the user’s security context, and so are exposed to a user with the right tools.
A frequently asked question is whether the RunAs.exe /savecred option would let one create a shortcut to run a single app as admin using a saved password and not requiring further password entry. There are several issues you should be aware of:
//TODO: Discuss my thoughts about the SRP/DropMyRights approach. (Bottom line: I dislike it.)
Much thanks for help and insight for this post goes to Eric Voskuil and Kevin Sullivan of DesktopStandard, and to Mark Russinovich and Wes Miller of Sysinternals/Winternals.