Principle of least privilege
In information security, computer science, and other fields, the principle of least privilege, also known as the principle of minimal privilege or just least privilege, requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user or a program on the basis of the layer we are considering) must be able to access only such information and resources that are necessary to its legitimate purpose.[1][2]
When applied to users, the terms least user access or least-privileged user account (LUA) are also used, referring to the concept that all users at all times should run with as few privileges as possible, and also launch applications with as few privileges as possible.
Usage
![]() | This article includes a list of references, related reading, or external links, but its sources remain unclear because it lacks inline citations. (April 2009) |
The principle of least privilege is widely recognized as an important design consideration in enhancing the protection of data and functionality from faults (fault tolerance) and malicious behavior (computer security).
The principle of least privilege is also known as the principle of least authority (POLA).
The kernel always runs with maximum privileges since it is the operating system core and has hardware access. One of the principal responsibilities of an operating system, particularly in multi-user operating system, is management of the hardware's availability and requests to access it from running processes. When the kernel crashes, the mechanisms by which it maintains state also fail. Even if there is a way for the CPU to recover without a hard reset, the code that resumes execution is not always what it should be. Security continues to be enforced, but the operating system can't respond to the failure properly because detection of the failure wasn't possible. This is because kernel execution either halted or the program counter resumed execution from somewhere in endless, and — usually — non-functional loop.
If execution picks up, after the crash, by loading and running trojan code, the author of the trojan code can usurp control of all processes. The principle of least privilege forces code to run with the lowest privilege/permission level possible so that, in the event this occurs — or even if execution picks up from an unexpected location — what resumes execution does not have the ability to do bad things. One method used to accomplish this can be implemented in the microprocessor hardware. In x86 architecture, the manufacturer designed two running "modes". (This term can be confusing because the term "mode" is used in certain OS variants to refer cumulatively, to the state of the set of bits associated with a given resource).
Least privilege is widely misunderstood and, in particular, is almost always confused with the Trusted Computer System Evaluation Criteria (TCSEC) concept of trusted computing base (TCB) minimization. Minimization is a far more stringent requirement that is only applicable to the functionally strongest assurance classes, viz., B3 and A1 (which are evidentiarily different but functionally identical).
Least privilege is often associated with privilege bracketing, that is, assuming necessary privileges at the last possible moment and dismissing them as soon as no longer strictly necessary, therefore ostensibly avoiding fallout from erroneous code that unintentionally exploits more privilege than is merited. Least privilege has also been interpreted in the context of distribution of discretionary access control (DAC) permissions, for example asserting that giving user U read/write access to file F violates least privilege if U can complete his authorized tasks with only read permission.
As implemented in some operating systems, processes execute with a potential privilege set and an active privilege set. Such privilege sets are inherited from the parent as determined by the semantics of fork(). An executable file that performs a privileged function—thereby technically constituting a component of the TCB, and concomitantly termed a trusted program or trusted process—may also be marked with a set of privileges, a logical extension of the notions of set user ID and set group ID. The inheritance of file privileges by a process are determined by the semantics of the exec() family of system calls. The precise manner in which potential process privileges, actual process privileges, and file privileges interact can become complex. In practice, least privilege is practiced by forcing a process to run with only those privileges required by the task. Adherence to this model is quite complex as well as error-prone.
Historically, the oldest instance of least privilege is probably the source code of login.c, which begins execution with super-user permissions and—the instant they are no longer necessary—dismisses them via setuid() with a non-zero argument.
Benefits
- Better system stability. When code is limited in the scope of changes it can make to a system, it is easier to test its possible actions and interactions with other applications. In practice for example, applications running with restricted rights will not have access to perform operations that could crash a machine, or adversely affect other applications running on the same system.
- Better system security. When code is limited in the system-wide actions it may perform, vulnerabilities in one application cannot be used to exploit the rest of the machine. For example, Microsoft states “Running in standard user mode gives customers increased protection against inadvertent system-level damage caused by "shatter attacks" and malware, such as root kits, spyware, and undetectable viruses”.
- Ease of deployment. In general, the fewer privileges an application requires the easier it is to deploy within a larger environment. This usually results from the first two benefits, applications that install device drivers or require elevated security privileges typically have additional steps involved in their deployment, for example on Windows a solution with no device drivers can be run directly with no installation, while device drivers must be installed separately using the Windows installer service in order to grant the driver elevated privileges.
Limitations
According to James Whittaker, in real practice, true least privilege is neither definable nor possible to enforce.[3] We have no method to evaluate a process to define the least amount of privileges it will ever need to perform its functions. That is because it is not possible to know all the values of variables it may process, all the addresses it will need, the precise time it needs etc. The best we can do in practice is restrict its privileges to eliminate some we casually predict that it will never need. This turns out to be far from the minimal set of privileges. This limitation substantially reduces the effectiveness of least privilege enforcement.
According to Barnum and Gegick, another limitation is the granularity of control that the operating environment (secure operating system) over privileges for an individual processes.[4] In real practice, it is almost never possible to control a process's access to memory, or processing time, or I/O device addresses or modes with the precision needed to eliminate the precise set privileges we can be sure a process will not need. This reduces its usefulness of this principle even more.
History
The original formulation is from Saltzer and Schroeder:
- Every program and every user of the system should operate using the least set of privileges necessary to complete the job. (The protection of information in computer systems, 1974)
Peter J. Denning, in his paper "Fault Tolerant Operating Systems" set it in a broader perspective among four fundamental principles of fault tolerance.
Dynamic assignments of privileges was earlier discussed by Roger Needham in 1972.[5][6]
See also
- Privilege escalation
- Capability and Capabilities vs. ACLs
- Confused deputy problem
- Privilege separation (or bracketing)
- Privilege revocation
- Rule of least privilege
- Need to know
- Compartmentalization (intelligence)
References
- ^ Saltzer 75
- ^ Denning 76
- ^ James Whittaker, Why secure applications are difficult to write, IEEE Security & Privacy, vol. 1, issue 2, pp. 81-83
- ^ Least Privilege
- ^ Roger Needham, [Protection systems and protection implementations], Proc. 1972 Fall Joint Computer Conference, AFIPS Conf. Proc., vol. 41, pt. 1, pp. 571-578
- ^ Schroeder Least Privilege and More
- Ben Mankin, The Formalisation of Protection Systems, Ph. D thesis, University of Bath, 2004
- P. J. Denning (1976). "Fault tolerant operating systems". ACM Computing Surveys. 8 (4): 359–389. doi:10.1145/356678.356680. ISSN 0360-0300.
{{cite journal}}
: Unknown parameter|month=
ignored (help) - Jerry H. Saltzer, Mike D. Schroeder (September 1975). "The protection of information in computer systems". Proceedings of the IEEE. 63 (9): 1278–1308. doi:10.1109/PROC.1975.9939.
- Deitel, Harvey M. An introduction to operating systems (revisited first ed.). Addison-Wesley. p. 673. ISBN 0-201-14502-2. page 31.
External links
- The Saltzer and Schroeder paper cited in the references.
- NSA (the one that implemented SELinux) talks about the principle of least privilege
- A discussion of the implementation of the principle of least privilege in Solaris
- "Proof that LUA makes you safer" by Dana Epp
- Applying the Principle of Least Privilege to User Accounts on Windows XP, by Microsoft
- Privilege Bracketing in the Solaris 10 Operating System, Sun Microsystems