Principle of least privilege

<h2 id="details">Details</h2>
The principle means giving any user accounts or processes only those privileges which are essentially vital to perform its intended functions. For example, a user account for the sole purpose of creating backups does not need to install software: hence, it 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 only when the situation absolutely demands it.
When applied to <a href="/facts/User_(computing)/zQRzG0KG">users</a>, the terms least user access or least-privileged user account (LUA) are also used, referring to the concept that all user accounts should run with as few <a href="/facts/Privilege_(computer_science)/7eS1wna4">privileges</a> as possible, and also launch applications with as few privileges as possible.
The principle (of least privilege) is widely recognized as an important design consideration towards enhancing and giving a much needed 'Boost' to the protection of data and functionality from faults (<a href="/facts/Fault_tolerance/rasrYlJk">fault tolerance</a>) and <a href="/facts/Computer_security/7E5dIy7G">malicious behavior</a>.
Benefits of the principle include:

<ul><li>Intellectual Security. 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 security targeted 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.</li>
<li>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 "<a href="/facts/Shatter_attack/RXyfcGh6">shatter attacks</a>" and <a href="/facts/Malware/5ee7TLFR">malware</a>, such as <a href="/facts/Root_kit/PV3NlgGC">root kits</a>, <a href="/facts/Spyware/NrVdv1by">spyware</a>, and undetectable <a href="/facts/Computer_virus/IyTC1usq">viruses</a>”.<a class="footnote-ref" id="fnref:2" href="#fn:2">2</a></li>
<li>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 <a href="/facts/Device_driver/rDYnHU1G">device drivers</a> 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.<a class="footnote-ref" id="fnref:3" href="#fn:3">3</a></li></ul>
In practice, there exist multiple competing definitions of true (least privilege). As <a href="/facts/Programming_complexity/HuVncxNS">program complexity</a> increases rapidly, 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.<a class="footnote-ref" id="fnref:4" href="#fn:4">4</a> 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.
The original formulation is from <a href="/facts/Jerome_H._Saltzer/VBf7aHTJ">Jerome Saltzer</a>:<a class="footnote-ref" id="fnref:5" href="#fn:5">5</a>

 Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.— <a href="/facts/Jerome_H._Saltzer/VBf7aHTJ">Jerome Saltzer</a>, <a href="/facts/Communications_of_the_ACM/Ix1DvEAk">Communications of the ACM</a>
<a href="/facts/Peter_J._Denning/semI7SRg">Peter J. Denning</a>, His paper "Fault Tolerant Operating Systems", set it in a broader perspective among "The four fundamental principles of fault tolerance".
"Dynamic assignments of privileges" was earlier discussed by <a href="/facts/Roger_Needham/sSz9TUYM">Roger Needham</a> in 1972.<a class="footnote-ref" id="fnref:6" href="#fn:6">6</a><a class="footnote-ref" id="fnref:7" href="#fn:7">7</a>
Historically, the oldest instance of (least privilege) is probably the source code of login.c, which begins execution with <a href="/facts/Super-user/0Brr6ol7">super-user</a> permissions and—the instant they are no longer necessary—dismisses them via setuid() with a non-zero argument as demonstrated in the <a href="/facts/Version_6_Unix/ev0YCVb4">Version 6 Unix</a> <a href="http://www.retro11.de/ouxr/u6ed/usr/source/s1/login.c.html#n:132">source code.</a>

<h2 id="implementation">Implementation</h2>
The <a href="/facts/Kernel_(operating_system)/uEj4U3Rz">kernel</a> always runs with maximum privileges since it is the <a href="/facts/Operating_system/8XTuvMh2">operating system</a> 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 <a href="/facts/Process_(computing)/Vcq7EnUV">processes</a>. When the kernel crashes, the mechanisms by which it maintains <a href="/facts/State_(computer_science)/4Yu8xXHS">state</a> also fail. Therefore, even if there is a way for the <a href="/facts/Central_processing_unit/Jxp1bqMV">CPU</a> to recover without a <a href="/facts/Hard_reset/mfSM0com">hard reset</a>, security continues to be enforced, but the operating system cannot properly respond to the failure because it was not possible to detect the failure. This is because kernel execution either halted or the <a href="/facts/Program_counter/BxqulBRq">program counter</a> resumed execution from somewhere in an endless, and—usually—non-functional <a href="/facts/Control_flow/2XTDfErC">loop</a>. This would be akin to either experiencing <a href="/facts/Amnesia/mbHoWW9p">amnesia</a> (kernel execution failure) or being trapped in a closed maze that always returns to the starting point (closed loops).

If execution picks up after the crash by loading and running <a href="/facts/Trojan_horse_(computing)/FVqh3nDy">trojan code</a>, 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. This means that the code that resumes the code execution-whether trojan or simply code execution picking up from an unexpected location—would not have the ability to perform malicious or undesirable processes. One method used to accomplish this can be implemented in the <a href="/facts/Microprocessor/Fx9CaQht">microprocessor</a> hardware. For example, in the <a href="/facts/Intel_x86/Kypq5fgu">Intel x86</a> architecture the manufacturer designed four (ring 0 through ring 3) running "modes" with graduated degrees of access-much like <a href="/facts/Security_clearance/d34w9Ksj">security clearance</a> systems in defence and intelligence agencies.
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 <a href="/facts/Fork_(operating_system)/M1jtvaT4">fork</a>(). An <a href="/facts/Executable_file/VSst9eLA">executable file</a> that performs a privileged function—thereby technically constituting a component of the <a href="/facts/Trusted_computing_base/QFA4q830">TCB</a>, and concomitantly termed a trusted program or trusted process—may also be marked with a set of privileges. This is a logical extension of the notions of <a href="/facts/Setuid/F2TnVj73">set user ID</a> and <a href="/facts/Setgid/F2TnVj73">set group ID</a>. The inheritance of <a href="/facts/File_privileges/DHq5SwI4">file privileges</a> by a process are determined by the semantics of the <a href="/facts/Exec_(system_call)/x9bn7lFr">exec</a>() family of <a href="/facts/System_calls/NW44AFJr">system calls</a>. 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.

<h2 id="similar-principles">Similar principles</h2>
The <a href="/facts/Trusted_Computer_System_Evaluation_Criteria/GCN1fjaE">Trusted Computer System Evaluation Criteria</a> (TCSEC) concept of <a href="/facts/Trusted_computing_base/QFA4q830">trusted computing base</a> (TCB) minimization is a far more stringent requirement that is only applicable to the functionally strongest assurance classes(Link to Trusted Computer System Evaluation Criteria section Divisions and classes), namely the classes <a href="/facts/Trusted_Computer_System_Evaluation_Criteria/GCN1fjaE">B3</a> and <a href="/facts/Trusted_Computer_System_Evaluation_Criteria/GCN1fjaE">A1</a> (which are functionally identical but differ in terms of evidence and documentation required).
Least privilege is often associated with <a href="/facts/Privilege_bracketing/sLBs8PmN">privilege bracketing</a>: 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 <a href="/facts/Discretionary_access_control/MTQRM7nr">discretionary access control</a> (DAC) permissions, for example asserting that giving user U read/write access to file F violates least privilege if U can complete their authorized tasks with only read permission.

<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/User_Account_Control/BjUhEq9u">User Account Control</a></li>
<li><a href="/facts/Capability-based_security/negzSwhS">Capability-based security</a></li>
<li><a href="/facts/Compartmentalization_(intelligence)/uFhJL55A">Compartmentalization (intelligence)</a></li>
<li><a href="/facts/Confused_deputy_problem/smReIHqa">Confused deputy problem</a></li>
<li><a href="/facts/Encapsulation_(object-oriented_programming)/kzDnbHPe">Encapsulation (object-oriented programming)</a></li>
<li><a href="/facts/Need_to_know/DoHevG3F">Need to know</a></li>
<li><a href="/facts/Privilege_bracketing/sLBs8PmN">Privilege bracketing</a></li>
<li><a href="/facts/Privilege_escalation/STzSAaf5">Privilege escalation</a></li>
<li><a href="/facts/Privilege_revocation_(computing)/97t6hvcI">Privilege revocation (computing)</a></li>
<li><a href="/facts/Privilege_separation/gLMQVMrp">Privilege separation</a></li>
<li><a href="/facts/Protection_ring/27y4kjHs">Protection ring</a></li>
<li><a href="/facts/Setuid/F2TnVj73">setuid</a></li>
<li><a href="/facts/Sudo/7jhmGdqg">sudo</a></li></ul>

<h2 id="bibliography">Bibliography</h2>

<ul><li>Ben Mankin, The Formalisation of Protection Systems, Ph.D. thesis, University of Bath, 2004</li>
<li><a href="/facts/P._J._Denning/semI7SRg">P. J. Denning</a> (December 1976). "Fault tolerant operating systems". <a href="/facts/ACM_Computing_Surveys/18Itftvp">ACM Computing Surveys</a>. 8 (4): 359–389. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.1145%2F356678.356680">10.1145/356678.356680</a>. <a href="/facts/S2CID_(identifier)/ldJsHa2Y">S2CID</a> <a href="https://api.semanticscholar.org/CorpusID:207736773">207736773</a>.</li>
<li>Jerry H. Saltzer, Mike D. Schroeder (September 1975). <a href="http://web.mit.edu/Saltzer/www/publications/protection/">"The protection of information in computer systems"</a>. Proceedings of the IEEE. 63 (9): 1278–1308. <a href="/facts/CiteSeerX_(identifier)/SceDmd3c">CiteSeerX</a> <a href="https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.126.9257">10.1.1.126.9257</a>. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.1109%2FPROC.1975.9939">10.1109/PROC.1975.9939</a>. <a href="/facts/S2CID_(identifier)/ldJsHa2Y">S2CID</a> <a href="https://api.semanticscholar.org/CorpusID:269166">269166</a>.</li>
<li>Deitel, Harvey M. (1990). <a href="https://archive.org/details/introductiontoopdeit00deit/page/673">An introduction to operating systems</a> (revisited first ed.). Addison-Wesley. p. <a href="https://archive.org/details/introductiontoopdeit00deit/page/673">673</a>. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 978-0-201-14502-1. page 31.</li>
<li>Sean Martin (April 2012). <a href="http://www.scmagazine.com/are-security-basics-getting-lost-under-the-cover-of-cloud-and-mobile/article/236285/">"Are security basics getting lost under the cover of cloud and mobile?"</a>. SC Magazine.</li>
<li>SANS Institute (May 2013). <a href="https://web.archive.org/web/20131101135802/http://www.sans.org/critical-security-controls/spring-2013-poster.pdf">"20 Critical Security Controls"</a> (PDF). SANS Institute. Archived from <a href="http://www.sans.org/critical-security-controls/spring-2013-poster.pdf">the original</a> (PDF) on 2013-11-01.</li></ul>

<h2 id="external-links">External links</h2>
<ul><li><a href="http://web.mit.edu/Saltzer/www/publications/protection/">The Saltzer and Schroeder paper cited in the references.</a></li>
<li><a href="https://web.archive.org/web/20080228180840/http://cyberforge.com/weblog/aniltj/archive/2004/05/26/544.aspx">NSA (the one that implemented SELinux) talks about the principle of least privilege</a></li>
<li><a href="https://web.archive.org/web/20050313003435/http://www.sun.com/bigadmin/features/articles/least_privilege.html">A discussion of the implementation of the principle of least privilege in Solaris</a></li>
<li><a href="http://silverstr.ufies.org/blog/archives/000913.html">"Proof that LUA makes you safer" by Dana Epp</a> <a href="https://web.archive.org/web/20100523093747/http://silverstr.ufies.org/blog/archives/000913.html">Archived</a> 2010-05-23 at the <a href="/facts/Wayback_Machine/nmQ3a6JC">Wayback Machine</a></li>
<li><a href="https://technet.microsoft.com/en-us/library/bb456992.aspx">Applying the Principle of Least Privilege to User Accounts on Windows XP, by Microsoft</a></li>
<li><a href="https://web.archive.org/web/20160309173053/http://www.csoonline.com/article/2131678/malware-cybercrime/commercial-enterprises-are-putting-our-critical-infrastructure-at-risk.html?page=1">"Commercial enterprises are putting our critical infrastructure at risk" CSO</a></li>
<li><a href="https://www.techrepublic.com/blog/it-security/how-to-successfully-implement-the-principle-of-least-privilege/">How to successfully implement the principle of least privilege</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1">Saltzer, Jerome H.; Schroeder, Michael D. (1975). "The protection of information in computer systems". Proceedings of the IEEE. 63 (9). Institute of Electrical and Electronics Engineers (IEEE): 1278–1308. doi:10.1109/proc.1975.9939. ISSN 0018-9219. OCLC 5871551104. S2CID 269166. <a href="/wiki/Jerome_Saltzer" target="_blank">/wiki/Jerome_Saltzer</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></li>
<li id="fn:2">Jonathan, Clark; DABCC Inc. "Virtualization Guru Writes "User-mode is a Good Thing - Deployment to Locked-down Accounts without Security Elevation"". Archived from the original on 10 February 2013. Retrieved 15 Mar 2013. <a href="https://web.archive.org/web/20130210034600/http://dabcc.com/article.aspx?id=4135" target="_blank">https://web.archive.org/web/20130210034600/http://dabcc.com/article.aspx?id=4135</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></li>
<li id="fn:3">Aaron Margosis (August 2006). "Problems of Privilege: Find and Fix LUA Bugs". Microsoft. <a href="https://technet.microsoft.com/en-us/magazine/cc160944.aspx" target="_blank">https://technet.microsoft.com/en-us/magazine/cc160944.aspx</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></li>
<li id="fn:4">"Matt Bishop, Computer Security: Art and Science, Boston, MA: Addison-Wesley, 2003. pp. 343-344 cited Barnum & Gegick 2005". Archived from the original on 2007-10-20. Retrieved 2007-11-17. <a href="https://web.archive.org/web/20071020000240/https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html" target="_blank">https://web.archive.org/web/20071020000240/https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></li>
<li id="fn:5">Saltzer, Jerome H. (1974). "Protection and the control of information sharing in multics". Communications of the ACM. 17 (7): 388–402. CiteSeerX 10.1.1.226.3939. doi:10.1145/361011.361067. ISSN 0001-0782. S2CID 326132. <a href="/wiki/Communications_of_the_ACM" target="_blank">/wiki/Communications_of_the_ACM</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></li>
<li id="fn:6">Needham, R. M. (1972). "Protection systems and protection implementations". Proceedings of the AFIPS '72 Fall Joint Computer Conference, December 5-7, 1972, Part I. pp. 571–578. doi:10.1145/1479992.1480073. S2CID 7371342. <a href="/wiki/Doi_(identifier)" target="_blank">/wiki/Doi_(identifier)</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></li>
<li id="fn:7">Fred B. Schneider. "Least Privilege and More" (PDF). <a href="http://www.cs.cornell.edu/fbs/publications/leastPrivNeedham.pdf" target="_blank">http://www.cs.cornell.edu/fbs/publications/leastPrivNeedham.pdf</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></li>
</ol>

Principle of least privilege open-in-new

Principle of least privilege