======================================================================
=                    Principle of least privilege                    =
======================================================================

                             Introduction                             
======================================================================
In information security, computer science, and other fields, the
principle of least privilege (PoLP), also known as the principle of
minimal privilege (PoMP) or the principle of least authority (PoLA),
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.


                               Details                                
======================================================================
The principle means giving any users account 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 users, 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 privileges 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
(fault tolerance) and malicious behavior.

Benefits of the principle include:

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

In practice, there exist multiple competing definitions of true (least
privilege). As program complexity 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 or one option worth mentioning and
giving the utmost security based reasoning, ponder this, in a
potential malicious environment the violators, (hackers) need as much
access to your infrastructure as possible. So, it stands to reason
that in a harmful instance if we stay off of our devices then at the
risk of 'stating the obvious' the less you use your device the more at
risk the user will be.. 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. 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 Jerome Saltzer:



Peter J. Denning, 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 Roger
Needham in 1972.

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
[http://www.retro11.de/ouxr/u6ed/usr/source/s1/login.c.html#n:132
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. Therefore, even
if there is a way for the CPU to recover without a hard reset,
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
program counter resumed execution from somewhere in an endless,
and—usually—non-functional loop. This would be akin to either
experiencing amnesia (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 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. 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 microprocessor hardware.
For example, in the Intel x86 architecture the manufacturer designed
four (ring 0 through ring 3) running "modes" with graduated degrees of
access-much like security clearance 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 '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. This is 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(Link to Trusted Computer System Evaluation Criteria
section Divisions and classes), namely the classes B3 B3 and A1 (which
are 'functionally' identical but differ in terms of evidence and
documentation required).

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                               
======================================================================
* User Account Control
* Capability-based security
* Compartmentalization (intelligence)
* Confused deputy problem
* Encapsulation (object-oriented programming)
* Need to know
* Privilege bracketing
* Privilege escalation
* Privilege revocation (computing)
* Privilege separation
* Protection ring
* setuid
* sudo


                             Bibliography                             
======================================================================
* Ben Mankin, 'The Formalisation of Protection Systems', Ph.D. thesis,
University of Bath, 2004
*
*
*  page 31.
*
*


                            External links                            
======================================================================
* [http://web.mit.edu/Saltzer/www/publications/protection/ The Saltzer
and Schroeder paper cited in the references.]
*
[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]
*
[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]
* [http://silverstr.ufies.org/blog/archives/000913.html "Proof that
LUA makes you safer" by Dana Epp]
* [https://technet.microsoft.com/en-us/library/bb456992.aspx Applying
the Principle of Least Privilege to User Accounts on Windows XP, by
Microsoft]
*
[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]
*
[http://www.techrepublic.com/blog/it-security/how-to-successfully-implement-the-principle-of-least-privilege/
How to successfully implement the principle of least privilege]


 License 
=========
All content on Gopherpedia comes from Wikipedia, and is licensed under CC-BY-SA
License URL: http://creativecommons.org/licenses/by-sa/3.0/
Original Article: http://en.wikipedia.org/wiki/Principle_of_least_privilege


.