العربية
中国
Français
Deutsch
Ελληνική
हिन्दी
Italiano
日本語
Português
Русский
EspañolPRINCIPLE OF LEAST PRIVILEGE
(Redirected from Least privilege)
In computer science and other fields the 'principle of minimal privilege', also known as the 'principle of least 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.
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 behaviour (computer security).
The principle of least privilege is also known as the 'principle of least authority' (POLA),
an alternative term coined by those who consider ''authority'' be a more precise term than ''privilege''
to represent "ability to access" in the true spirit of this concept. Specifically, ''authority'' represents all effects that a subject can directly or indirectly cause in a system, as opposed to ''permission'' which represents the effects that can be directly caused in a single operation.
In operating systems like Windows there is no security enforcement for code running in kernel mode and therefore such code always runs with maximum privileges. The principle of least privilege therefore demands the use of a user mode solutions when given the choice between a kernel mode and user mode solution if the two solutions provide the same results.
Least privilege is widely misunderstood and, in particular, is almost always confused with the TCSEC concept of 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—and arguably incorrectly—been interpreted in the context of distribution of discretionary access control permissions, even to the point of asserting that, ''e.g.'', giving user U read/write access to file F violates least privilege if U can complete his authorized tasks with only read permission.
In an archetypal UNIX implementation, 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 (TP) 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 may be quite involved. In practice, least privilege is practiced by maintaining in the active privilege set only those privileges that are strictly necessary at the time, claiming and dismissing them from the potential privilege set as appropriate. Strict 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.
★ 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.” [1]
★ 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 addition 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.
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.[1][2]
★ Privilege escalation
★ Capability and Capabilities vs. ACLs
★ Confused deputy problem
★ Privilege bracketing
★ Privilege revocation
★ Privilege separation
★ Need to know
★ Least user access
★ Ben Mankin, ''The Formalisation of Protection Systems'', Ph.D thesis, University of Bath, 2004
★ Fault tolerant operating systems, P. J. Denning, , , ACM Computing Surveys (CSUR), 1976
★
★ An introduction to operating systems, , Harvey M., Deitel, Addison-Wesley, 1984, ISBN 0-201-14502-2 page 31.
★ [2] The Saltzer and Schroeder paper cited in the references.
★ [3] NSA (the one that implemented SELinux), talks about the principle of least privilege
★ [4] A discussion of the implementation of the principle of least privilege in Solaris
In computer science and other fields the 'principle of minimal privilege', also known as the 'principle of least 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.
| Contents |
| Usage |
| Benefits |
| History |
| See also |
| References |
| External links |
Usage
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 behaviour (computer security).
The principle of least privilege is also known as the 'principle of least authority' (POLA),
an alternative term coined by those who consider ''authority'' be a more precise term than ''privilege''
to represent "ability to access" in the true spirit of this concept. Specifically, ''authority'' represents all effects that a subject can directly or indirectly cause in a system, as opposed to ''permission'' which represents the effects that can be directly caused in a single operation.
In operating systems like Windows there is no security enforcement for code running in kernel mode and therefore such code always runs with maximum privileges. The principle of least privilege therefore demands the use of a user mode solutions when given the choice between a kernel mode and user mode solution if the two solutions provide the same results.
Least privilege is widely misunderstood and, in particular, is almost always confused with the TCSEC concept of 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—and arguably incorrectly—been interpreted in the context of distribution of discretionary access control permissions, even to the point of asserting that, ''e.g.'', giving user U read/write access to file F violates least privilege if U can complete his authorized tasks with only read permission.
In an archetypal UNIX implementation, 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 (TP) 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 may be quite involved. In practice, least privilege is practiced by maintaining in the active privilege set only those privileges that are strictly necessary at the time, claiming and dismissing them from the potential privilege set as appropriate. Strict 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.” [1]
★ 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 addition 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.
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.[1][2]
See also
★ Privilege escalation
★ Capability and Capabilities vs. ACLs
★ Confused deputy problem
★ Privilege bracketing
★ Privilege revocation
★ Privilege separation
★ Need to know
★ Least user access
References
★ Ben Mankin, ''The Formalisation of Protection Systems'', Ph.D thesis, University of Bath, 2004
★ Fault tolerant operating systems, P. J. Denning, , , ACM Computing Surveys (CSUR), 1976
★
★ An introduction to operating systems, , Harvey M., Deitel, Addison-Wesley, 1984, ISBN 0-201-14502-2 page 31.
External links
★ [2] The Saltzer and Schroeder paper cited in the references.
★ [3] NSA (the one that implemented SELinux), talks about the principle of least privilege
★ [4] A discussion of the implementation of the principle of least privilege in Solaris
This article provided by Wikipedia. To edit the contents of this article, click here for original source.
psst.. try this: add to faves
