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

[David Wagner]

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

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.