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

[Toby Murray]

On Mon, 2007-09-17 at 16:27 -0700, David Wagner wrote:
> Toby Murray writes:
> >That said, I'd like to know why my stated definition is not useful as a
> >definition of what it means for a system to be secure.
> 
> For the same reason I just stated: it conflates "following a specific
> implementation technique" with the end goals we have in mind.  I feel
> like I'm repeating myself but I don't know how to re-state it differently.
> Following POLA doesn't imply that a system is secure.  A component might
> be given no more authority than it needs, but still might miswield or
> misuse that authority.
> 
> Consider a mail client which has a mode of operation where it inserts
> the word 'not' at just the right place in an important email to reverse
> the meaning of the email message ("I am willing to offer you $1000 for
> your product" -> "I am not willing to offer you...").  Suppose that
> an adversary can trigger that mode of operation.  Such a mail client
> might not exceed the authority granted to it.  It might not exceed
> the authority that it needs to perform its job.  After all, the only
> difference between this buggy mail client and a good mail client lies
> in the purely computational logic, and pure computation is normally
> understood to involve no authority at all.  Yet I'd be reluctant to
> consider such a mail client "secure".

But this is an example in which my definition works. The mail client is
insecure, not because it doesn't respect POLA but because it has more
authority than I'm willing to trust it with. This is precisely my
definition in action.

I'm wondering why you consider my definition to be a design goal. It
isn't intended to be one. It's intended to be a means for someone to
decide whether a system is secure from their point of view.

> 
> Suppose I want a house that will be reliable, and I use "follows local
> building codes" as my definition of reliability.  That might not be the
> best possible course.  It overlooks the possibility that following local
> codes might not be sufficient to ensure the level of reliability I have
> in mind.  For instance, in many places local codes are not sufficient to
> ensure that my house will stay standing after a large earthquake; if I had
> in mind that I wanted a house that would survive a large earthquake, then
> that was not the right definition to use.  That definition also doesn't
> help you the local town counsel decide what local building codes should
> or shouldn't require, which is a sign that it is not a good definition.

Yes. But my definition isn't trying to be a design guideline for secure
systems. One /cannot/ apply my definition like that because one cannot
reason about the degree to which real-world stakeholders will be willing
to trust the (various components of) system when it is fielded.

Are we going in circles? ;)