Talk:Principle of least privilege

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Security (Rated Start-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computer Security (marked as High-importance).

widely recognized

I don't see why POLP is used... are there benefits other than widely recognized?

What benefits are widely recognized?[edit]

The Principle of Least privilege cannot create a set of hard solid rules anymore than one of Aesop's Fables can. But that's not the point, and should not be the focus of this article.

It's meant to inspire discussion of which privileges are appropriate, and to help those who aren't security professionals understand how the security professionals try to accomplish their jobs. That should be the focus of this article. —Preceding unsigned comment added by (talk) 21:03, 12 August 2008 (UTC)

Note least privilege can neither be determined nor enforced. Some have proposed a more realistic objective of principle of 'small' privilege, but there is little chance of defining 'small' in a useful way.
This is used as a non-specific attempt to reduce the scope of things a process can do in blind hope of eliminating its ability to do something essential to disruptive behavior. This is used as an axillary measure to make penetration more difficult. It cannot absolutely guarantee prevention of anything.
Unfortunately, because of problems enforcing this principle, it is not very effective. It is often used as a buzz word when good security is viewed as too hard. John (talk) 05:42, 17 November 2007 (UTC)
Restricting access privileges reduces the opportunities for insider threats to exploit information. But it does not eliminate them. Least privilege implies a minimal set privileges can be defined and that the granularity of control over privileges can distinguish between that minimal set and something close to the minimal. The technical problem arises in when we start thinking we can reduce privileges to the minimal set, or when we start thinking we can even begin to define such a set. That is an uninformed viewpoint, and is the reason why many informed people view the “Principle of Least Privilege” as unattainable, little more than a buzzword for uninformed discussions. John (talk) 16:14, 14 August 2008 (UTC)

Tislinthi (talk) 04:06, 18 November 2008 (UTC) This article seems to be written by someone who does not agree with the utility of the POLP, yet is unable to present convincing arguments as to why the principle is not valid. Limiting what users can do is a fundamental defensive technique, so basic that I wonder why it would even be questioned. I understand that it can be annoying not to have all the privileges one would like, but the fact remains that not everyone can be trusted, and there aren't many ways of knowing in advance who should be given greater power than the minimum necessary. Consider this quote: "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." It is claimed that application of least privilege to file protection is arguably incorrect - yet where is the argument? Why would someone allow their files to be modified by anyone other than a restricted set of users? It seems basic good sense, and not at all a far-fetched assertion, that a file system be protected from random modification. I guess what bothers me is that this article presents factual information about the POLP, but does so with an unfavorable and unsupported bias against it, which undermines the article's value.

It appears you compare a "restricted set of users" to "least privilege." You can define the former but not the latter. We need to use terms and concepts that we can define, and PLOP lacks this property.
Hardly anyone would disagree that restricting access privileges helps security. Its effectiveness is sometimes overrated, and even its name offers more than can be delivered. Since least privilege is not definable by its literal meaning, there is no consensus on what it means, there is no way to know when we are done implementing it. That means someone can sell us a system and claim it implements PLOP and we cannot determine if it is really implemented. It is really just a vague notion of reducing privilege by some arbitrary degree, too often too little too late. Offering PLOP as an easier substitute for mechanisms that can offer absolute guarantees of security is what sometimes gives it bad press. The benefits are almost impossible to establish; it surely must be a good thing, but there is no way to decide how much good it does. When things cost money, people usually want certain or measurable benefits. Personally, I would implement it, and do so conscientiously, but I would not depend on it much. John (talk) 06:12, 19 November 2008 (UTC)
One could also argue that the term "security" is just as undefinable, and just as unmeasurable. In general there is no way of offering an absolute guarantee of security. Just because a principle is not precisely definable or testable doesn't mean that it is invalid. —Preceding unsigned comment added by (talk) 02:33, 10 September 2009 (UTC)

I don't really understand why[edit]

I can see why there needs to be some kind of hierarchy when users are working within an organization, as far as they need only the privileges/accesses necessary to perform their jobs. However, I think there needs to be a different kind of approach to this problem... flat out "denying access" to certain apps within a program often tends to frustration... because the procedures and permissions associated to that person's security access are often just "assumed" by the person delegating the access. It seems a bit abstract and arbitrary.

I agree that there are many cases where hierarchy is not applicable. Sometimes when it is applicable, some should have more access than others. For example, the engineer may need to know the performance details, and payroll may need to know the salaries, but the converse may not be true, and the boss may need to know both. John (talk) 16:10, 14 August 2008 (UTC)

"According to James Whittacker..."[edit]

James Whittacker is a 79-year-old mountaineer, not a computer security commentator. Wrong James Whittacker probably?-- (talk) 00:46, 2 January 2009 (UTC)

Someone apparently already fixed his name to "James Whittaker". But there is a bigger problem. In his article he does not !!! claim that "In practice, true least privilege is neither definable nor possible to enforce." (or anything equivalent). Kosik (talk) 11:22, 27 December 2010 (UTC)

section request: glossary[edit]

"powerbox" from HP Polaris is a red link, and IMO it should go to an entry in a list of POLA jargons, possibly external to wikipedia. (talk) 18:33, 9 February 2011 (UTC)