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

[Toby Murray]

On Mon, 2007-09-17 at 15:35 +0100, David Hopwood wrote:
> Toby Murray wrote:
> > Hi cap-talk,
> > 
> > In my work on formalising authority, I've found it useful to strengthen
> > the usual notion of POLA to arrive at a more general definition of what
> > it means for a system to be 'secure'.
> > 
> > The traditional definition of POLA says that 
> > 
> > "the authority of each object/subject/program/process/user/whatever
> > should not exceed that needed for it to perform its function(s)."
> > 
> > This is useful but doesn't admit notions such as "separation of duty"
> > which need to be defined separately (because they appear orthogonal to
> > the above definition).
> > 
> > It also presumes there is some global administrator that can define the
> > correct function(s) of each entity in the system.
> 
> Correct function does not have to be decided by an administrator.

Good point.

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

Indeed. This is what I'm trying to get at. 

I think we need a definition of security that takes into account a
user's perceptions. I don't think POLA does this adequately in some
cases. 

>  A user's
> choice not to trust something is entirely up to that user. 

As is a user's perception about whether a system is "secure". Having a
formal definition of security that coincides with the user's perceptions
is surely a good thing.

> They don't
> have to justify their decision, and the decision doesn't even need to
> have any rational basis -- it should be respected anyway (as far as
> possible; if the component is in the system TCB then the user's only
> recourse is not to use the system).

Absolutely. That's why I'm interested in this property. The property we
want to enforce is that the program doesn't exceed the authority the
user expects it to have. POLA doesn't capture this, which is why I'm
using a different definition.

>  So a particular user's trust in a
> component is not an objective property of that component.

Of course. But neither is the property of whether the component is
"secure". 

> 
> POLA, OTOH, should be defined relative to the intended function of a
> component. 

Who gets to decide "intended"? If it's the user then I think we arrive
at the same property. If it's the application developer, then one could
argue that all Trojans adhere to POLA when run on ambient authority
OSes. A trojan author certainly intends for it to cause damage. ;)

> This makes it a (somewhat) objective property of the component's
> design. 

You're presuming that the component is designed to carry out its
"intended" function, which it may not be.

> Yes, there may be disagreement on what the intended function
> is, and to assess how well a given component satisfies POLA, we need to
> resolve that disagreement. But the assessment does not depend on who
> will trust the component and who won't.

I think it does. Resolving the disagreement about intended functionality
of a Trojan is absolutely a question of trust. I think that resolving
the question for this case boils down to the same thing as answering the
qeustion of "what do I trust this thing to do?".

Hence I suspect that what you and I might not be so far apart as we may
seem.

In David's other reply:

On Mon, 2007-09-17 at 15:48 +0100, David Hopwood wrote: 
> I missed part of Toby's mail:
> 
> Toby Murray wrote:
> > It also naturally admits separation of duty:
> > 
> > We might have an accounting package whose functions include writing and
> > approving purchase orders, for example. A running instance of that
> > package might be trusted to perform the former but not the latter (and
> > vice versa) in order to prevent it from approving its own purchase
> > orders.
> 
> In this case the package's intended function is for each instance to
> be able to write or approve (but not both) a set of purchase orders.

Not necessarily. Only if the package has been written with the
separation of duty policy in mind is this its intended function.

Perhaps we're disagreeing about who decides what the intended function
is. Perhaps what you mean by "intended function" is the same thing as
what I mean by "what I'm willing to trust this thing to do". In which
case, there is no distinction.

> I don't see that any generalization is needed to cover separation of
> duty; it is part of what I've always considered POLA to cover.

I had always thought that POLA doesn't cover separation of duty. In
particular, fwiw, Saltzer and Schroeder felt it necessary to distinguish
least privilege and separation of duty.

> A more common example is that each instance of an editor should only
> be able to read and write files designated by the user for that
> instance; not any file that the editor program has ever been asked
> to edit. (There is a nontrivial, but solvable, design problem here in
> how to support 'Recently used file' lists.)

I don't see any separation of duty here. I would agree that the editor
example is pure POLA. It also satisfies my definition when the user
trusts the editor instance to edit (only) the file that is currently
open.