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

[Toby Murray]

On Mon, 2007-09-17 at 18:18 +0100, David Hopwood wrote:
> Toby Murray wrote:
> > On Mon, 2007-09-17 at 11:00 -0400, Jonathan S. Shapiro wrote:
> >> On Mon, 2007-09-17 at 15:35 +0100, David Hopwood wrote:
> >>> Toby Murray wrote:
> >>>> Instead, I've found that a better definition of what we might desire is
> >>>>
> >>>> "the authority of each object/subject/... should not exceed that which
> >>>> we trust it to wield."
> >>>
> >>> I don't think that switching from "needed to perform its function" to
> >>> "which it is trusted to wield" is an improvement on the definition
> >>> of POLA. I think it's defining something else. A program can very well
> >>> satisfy POLA, and a particular user still does not trust it. [...]
> 
> Conversely, a user may trust something to a greater extent than is
> justified by its intended function.

I can't imagine how. (Again, more disconnect ;)

One of my (I now realise unstated) assumptions is that the user never
trusts things with more power than what they believe is needed for them
to carry out the user's wishes. The user doesn't trust the application
to (be able to) do anything the user doesn't want it to do.

>  So I agree with Jonathan that this
> change would considerably weaken the definition of POLA.
> 
> >> More strongly: I think it's a significant weakening of the concept and a
> >> misguided statement of design goal (Toby: I'm objecting to the framing,
> >> not necessarily to your true goal).
> > 
> > I think I see where the disagreement comes from. I'm not trying to
> > propose a design goal. POLA might well be the strongest design goal one
> > can hope for. I'm trying to propose a criterion that can be used to
> > determine whether a system is secure from a particular stakeholder's
> > point of view.
> 
> There are at least two problems with this:
> 
> 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.

I don't follow. If a stakeholder has insufficient information, surely
the only correct decision is to not trust the subsystem and, hence, be
willing for it to wield almost zero authority. That's the point of my
definition.

> 
>    A system that follows POLA derives much of its overall security (and
>    reliability) from limiting the propagation of faults and exploits. That
>    depends on POLA being defined in terms of authority needed for intended
>    function, even when any particular stakeholder would have been prepared
>    to trust each component with more authority than it needed. IOW, it is
>    not true that a system will be secure if it only limits authority
>    according to trust, rather than according to need. If it only limits
>    authority according to trust, then any errors in trust assessments will
>    allow exploits to propagate.

Yes I should have been more clear. I'm not proposing this idea as a
design goal. I'm proposing it as a definition that I can formally
specify for when a system is insecure from the point of view of a
particular stakeholder.

> 
> 2. If the authority provided to a component is less than it needs to perform
>    the functions requested of it, then it will fail. For effective and
>    usable security, it is as important to minimize failures due to
>    insufficient authority, as to prevent excess authority.
> 
>    The default policy that we often assume when talking about
>    capability-based user interfaces, is based on the premise that the
>    actions a user tries to perform are a more accurate indication of how
>    much trust the user places in the components that will implement that
>    action, than any predetermined, static policy. 

That's why these systems are secure -- because authority is aligned with
trust. This is precisely from where some of the inspiration  for my
definition comes.

> If a user requests (via
>    a trusted path) to edit a file, then we *assume* that the user trusts
>    the editor instance to read and write that file.

This is why we grant the editor the authority -- because of this
assumption about trust. We grant the editor the authority because we
infer that the user trusts it to edit the file. Authority doesn't exceed
trust. We must be talking past each other or I must be missing something
because this only seems to reinforce my definition.

>  We don't separately
>    *ask* whether the user trusts the editor instance (which would result
>    in security dialog fatigue), nor do we require that the user first set
>    up static permissions (such as ACLs) that allow the editor program to
>    access any file that *might* need to be edited.

Indeed, but I'm failing to see your point. 

I'd really like to get to the bottom of this. I'm hoping you'll
elaborate further and thanks for the debate so far. It's helped me to
clarify my thinking on this stuff. I'm hoping we can reach some
agreement, or I can see why my definition is less than useful.