[cap-talk] POLP v. POLA

Tyler Close tyler.close at gmail.com
Sun Oct 30 12:52:04 EST 2005


On 10/29/05, Ian G <iang at systemics.com> wrote:
> My question is this:  is there any substantial difference
> between this principle and POLA?

The key difference between essays that speak in terms of POLP
(Principle of least privilege) and POLA (Principle of least authority)
is nicely captured by a quote from the Saltzer and Schroeder essay on
the scope of their analysis:

"The final model (only superficially  explored) is of protected objects and
protected subsystems, which  allow arbitrary modes of sharing that are
unanticipated by the  system designer."

POLA encompasses analysis of all the ways in which authority flows in
designs composed of protected objects and protected subsystems. In
general, a POLP analysis fails to capture some of these flows.

Interestingly, there is an example of such a failure in the Saltzer
and Schroeder essay. In the section discussing the ACL model, the
authors write:

"4. The question of "who may access this segment?"  apparently is
answered directly by examining the  access control list in the access
controller for the  segment. The qualifier "apparently" applies because we
have not yet postulated any mechanism for controlling  who may modify access
control lists.."

The above represents only a POLP analysis of the question. A POLA
analysis would additionally determine who may learn the contents of
the segment by sending a request to a principal that is directly
authorized to read the segment, and so on, recursively.

Informally, I also use the POLP vs POLA distinction as a shibboleth
for distinguishing authors with a deeper understanding of the problem.
For example, the above question posited by Saltzer and Schroeder is
itself flawed. The question is not "who may access this segment", but
"who is to be held accountable for accesses to this segment".  The
former question reflects a crucial misunderstanding of what it means
to delegate access. Delegating access must not absolve the delegator
of responsibility for the actions of the delegatee. If you only answer
the question of who made the actual invocation, you misunderstand who
is actually responsible for the consequences of the invocation. Once
you understand that accountability is the key issue, you realize that
the identity of the requestor is irrelevant and can only confuse the
analysis.

Tyler

--
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/extensions/moreinfo.php?id=957



More information about the cap-talk mailing list