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

[Valerio Bellizzomi]

On 17/09/2007, at 16.08, Toby Murray wrote:

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

With persistence the problem of MRU file lists should be trivial: the
editor is persistent, and the MRU file list is per-instance. When an
editor process is dismantled, the in-memory list goes away.
There could be an option to save the per-instance MRU list in a
user-defined file, that could be used later (from a user interface menu)
to re-designate MRU files to other instances of the editor.

val