Principle of least privilege

Not to be confused with Rule of least power.

In information security, computer science, and other fields, the principle of least privilege (also known as the principle of minimal privilege or the principle of least authority) requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user, or a program, depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose.[1][2]

Details

The principle means giving a user account only those privileges which are essential to that user's work. For example, a backup user does not need to install software: hence, the backup user has rights only to run backup and backup-related applications. Any other privileges, such as installing new software, are blocked. The principle applies also to a personal computer user who usually does work in a normal user account, and opens a privileged, password protected account (that is, a superuser) only when the situation absolutely demands it.

When applied to users, the terms least user access or least-privileged user account (LUA) are also used, referring to the concept that all user accounts at all times should run with as few privileges as possible, and also launch applications with as few privileges as possible. Software bugs may be exposed when applications do not work correctly without elevated privileges.

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).

Benefits of the principle include:

In practice, there exist multiple competing definitions of true least privilege. As program complexity increases at an exponential rate, so do the number of potential issues, rendering a predictive approach impractical. Examples include the values of variables it may process, addresses it will need, or the precise time such things will be required. Object capability systems allow, for instance, deferring granting a single-use privilege until the time when it will be used. Currently, the closest practical approach is to eliminate privileges that can be manually evaluated as unnecessary. The resulting set of privileges typically exceeds the true minimum required privileges for the process.

Another limitation is the granularity of control that the operating environment has over privileges for an individual process.[5] In practice, it is rarely possible to control a process's access to memory, processing time, I/O device addresses or modes with the precision needed to facilitate only the precise set of privileges a process will require.

History

The original formulation is from Jerome Saltzer:[6]

Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.
— Jerome Saltzer, Communications of the ACM

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.[7][8]

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 as demonstrated in the Version 6 Unix source code.

Implementation

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 a 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 cannot respond to the failure properly because detection of the failure was not 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 code execution picks up from an unexpected location—what resumes the code execution would not have the ability to perform malicious or undesirable things. One method used to accomplish this can be implemented in the microprocessor hardware. In the Intel x86 architecture, the manufacturer designed four (ring 0 through ring 3) running "modes".

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.

Similar principles

The Trusted Computer System Evaluation Criteria (TCSEC) concept of trusted computing base (TCB) 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 reducing 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.

See also

Notes

  1. ↑ Saltzer 75
  2. ↑ Denning 76
  3. ↑ Jonathan, Clark; DABCC Inc. "Virtualization Guru Writes "User-mode is a Good Thing - Deployment to Locked-down Accounts without Security Elevation"". Retrieved 15 Mar 2013.
  4. ↑ Aaron Margosis (August 2006). "Problems of Privilege: Find and Fix LUA Bugs". Microsoft.
  5. ↑ Matt Bishop, Computer Security: Art and Science, Boston, MA: Addison-Wesley, 2003. pp. 343-344 cited Barnum & Gegick 2005
  6. ↑ Saltzer, Jerome H. (1974). "Protection and the control of information sharing in multics". Communications of the ACM 17 (7): 389. doi:10.1145/361011.361067. ISSN 0001-0782.
  7. ↑ Roger Needham, Protection systems and protection implementations, Proc. 1972 Fall Joint Computer Conference, AFIPS Conf. Proc., vol. 41, pt. 1, pp. 571-578
  8. ↑ Schneider, Least Privilege and More

References

External links

This article is issued from Wikipedia - version of the Thursday, March 17, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.