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

[David Hopwood]

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. 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.

   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.

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. 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. 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.

   (The above policy is not the only one that can be supported by a
   capability system, but it is probably a good default for single-user
   desktop machines, and it's significantly better than what current
   non-capability systems provide. We can additionally use VOC mechanisms
   to make it easier for users to comply with some administratively decided
   policy.)

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>