The idea being that you give a process only the authority it needs to accomplish its job. Also known as
the PrincipleOfLeastAuthority (especially in ObjectCapabilityModel circles).

For example, consider a program needing to write a log to disk.  There are several possible privileges that could allow this, including:
	* Raw disk access
	* Read/write rights to a single directory
	* Read/write rights to a supplied file
	* Rights to a supplied output stream

The finer grained the security mechanism, the closer you can get to the least privilege, and therefore the closer you get to complete security.  

Granted, completely secure systems only exist theoretically, but practically speaking, you can get as close as you'd like.

''Micromanaging privileges is labor-intensive.''

That's why you don't manage privileges, you let the operating system handle capabilities.  When you supply a file to a program, you're doing the same micromanagement required by capabilities, except that you give the program the capability to a file, and not the filename + privileges to the file based on the program's identity.  It's actually less work than managing a typical permissions system.

----

But keep in mind that POLA is a ''principle'' of security design, not a hard and fast rule that must be adhered to at all times, no matter what the cost. If you don't understand what that means then see ThreeLevelsOfAudience, because POLA is for a level 2 audience.

The antithesis of POLA is the unification of legitimately inseparable privileges. If two privileges can't be ''legitimately'' (in a meaningful and just manner) separated so that a person has only one or the other then they should be unified such that it's impossible to separate them.

* ''How is this "the antithesis of POLA"? It's just a case where no meaningful reduction of authority could be obtained by separating the privileges (= permissions in this context), and so the principle doesn't apply -- which is entirely different from it being broken. See PrincipleOfLeastAuthority for the distinction between "authority" and "permission".''

* It's the antithesis of POLA because it is false that a single unified privilege can't "meaningfully" be split up just because it's pointless, and arbitrary to do so. You're embuing the word "meaningful" with a meaning it simply doesn't have.

For example, the type of a file and its name are two privileges that can't be legitimately separated. If a user gets to access or redefine one, then they should be allowed to access or redefine the other one as well. The only difference between them is that one communicates usage information to human beings, while the other performs the same function to the machine. These cannot be legitimately separated, no matter how often authoritarians (eg, fans of BondageAndDisciplineLanguage''''''s with StaticTyping) like to do so.

Another example is the position of an object in the GUI's 3-space and its name. If arbitrary positioning isn't allowed then the objects' name decides its position, modulo a sortBlock of some kind. If arbitrary positioning is allowed then the object's position should be just as accessible as its name (preferably by encoding it ''in'' the name). The privileges of hiding an object in the 3-space and hiding it by mangling its name, can't be meaningfully separated.

There are many, many ways of structuring privileges. The forces of unification and minimalism pull in opposite directions. The designer's job is to find the sweet spot in between them. The place where they cancel out.

----
Contributors:  WilliamUnderwood, RichardKulisz
----
CategorySecurity