How to Get Programs to Run While Logged in as a Member of the Users Group
What is the Priciple of Least Privilege (PLP)?
In information security & computer science the principle of least privilege, or just least privilege, requires that a user, a program, or a process/service should only have access to the information and resources that are necessary to do its job.
Part of implementing least privilege is to not allow users to log in as members of the Administrators group or as a root user.
It is good practice to when first setting up a computer, where the first account is an administrator, is to immediately create a new standard user account, and then switch to the standard user account to do any further installs and configuration.
Microsoft refers to the principal of least privilege as LUA. The acronym LUA generally refers to Least-Privilege User Account, but is sometimes defined as Limited User Account, Least User Access, and several other variations. But whatever the letters stand for, the concept is the same. LUA is a computer user account that cannot make changes that affect other users of the system or the operating system itself. In Windows, these are typically members of the built-in Users group. Members of this group are explicitly not members of powerful groups (such as Administrators, Power Users, and Backup Operators) and they do not hold elevated privileges (like Load and unload device drivers, and Act as part of the operating system). Unfortunately, LUA can surface a number of issues.
- The Protection of Information in Computer Systems by Saltzer and Schroeder
- National Institute of Standards and Technology :-: Role Based Access Control (RBAC)
- NIST: Access Rights Management for the Financial Services Sector
- Principle of Least Privilege at Wikipedia.org
- Role based access control (RBAC)
- Problems of Privilege: Find and Fix LUA Bugs
- Applying the Principle of Least Privilege to User Accounts on Windows Vista
- Implementing Least-Privilege Administrative Models
Why You Should Not Run as an Administrator or Root User
If a system is compromised, by malware or an unauthorized user, that user or malware will have the same privileges of the logged-on user. If the current user is an administrator or root user, then the malware/unauthorized user will have full reign to do whatever they wanted to the system, without the user’s knowledge or interaction. If the current user was not an administrator or root user, e.g. a Limited User or Standard User, then the malware/unauthorized user should be restricted to what they can access and to how much damage they can inflict on the system.
If you’re running as an administrator or root user, an exploit can:
- install kernel-mode rootkits and/or keyloggers (which can be impossible to detect)
- install and start services
- install ActiveX controls, including Internet Explorer and shell add-ins (common with spyware and adware)
- access data belonging to other users
- cause code to run whenever anybody else logs on (including capturing passwords entered into the Ctrl-Alt-Del logon dialog)
- replace OS and other program files with trojan horses
- access LSA Secrets, including other sensitive account information, possibly including account info for domain accounts
- disable/uninstall anti-virus
- cover its tracks in the event log
- render your machine unbootable
- Why you shouldn’t run as admin by Aaron Margosis
- The Desktop Files: Leaving the Administrator Behind by Wes Miller
- Windows Administration: Gaming in a Secure Environment by Matt Clapham
- Learn why you need to ditch Admin rights by Sami Laiho (Microsoft Ignite)
- Coding Horror: Trojans, Rootkits, and the Culture of Fear
- Windows 2000 Secondary Logon (Run As)
- Minimizing User Rights Can Increase Security [eWeek]
- Malware and administrative rights
- How to set up a local account in Windows 10 during or after installation