[cap-talk] Reinterpreting POLA - "Authority Must Not Exceed Trust"

[ihab.awad at gmail.com]

On 9/17/07, David Hopwood <david.hopwood at industrial-designers.co.uk> wrote:
> 1. This criterion is based on a stakeholder being able to make an accurate
>    trust assessment for every component that they depend on. It assumes that
>    each stakeholder has sufficient information and competence to make this
>    assessment. But they very often don't.

The fact of under-informed stakeholders should not be an impediment to
thinking about how *better*-informed stakeholders might reason, then
back-calculating the ways in which our system may mimic a
better-informed stakeholder.

>    A system that follows POLA derives much of its overall security (and
>    reliability) from limiting the propagation of faults and exploits. ... If it only
>    limits authority according to trust, then any errors in trust assessments
>    will allow exploits to propagate.

I'm not sure what Toby is proposing, but I wonder about the
*intersection* of the least authority to perform the task with the
maximum authority indicated by the level of trust in the component.

> 2. If the authority provided to a component is less than it needs to perform
>    the functions requested of it, then it will fail.

As some components rightly deserve to! :)

I wager there are ways in which a clever component author can compose
authorities granted by even the most careful end-user to achieve
effects outside the user's intent (which is my working definition of
the verb 'to p3wn'). Were things otherwise, the game of chess would be
quite dull.

Although POLA *limits* these unplanned effects, and is therefore a
desireable baseline, we can *further* limit these effects by bringing
to bear whatever other common sense we may have. For example, such
common sense may involve the progeny of a component, and its
consequent likelihood to misbehave.

We should of course be careful that this common sense does not lull us
away from maintaining as strict a POLA as possible.

Back-calculating to how we can *build* this common sense, imagine a
highly critical subsystem where, as a condition of entry, the code of
any component executed within the system must be signed. A public
author blacklist, maintained by a third party, can then provide a
safeguard against known, deliberate attackers.

Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA