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

[David Wagner]

David Wagner writes:
> 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".

Toby Murray writes:
>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 don't see it.  Let the Buggy Mailer be as I described above.  Let the
Nonbuggy Mailer be similar to the Buggy Mailer, except it does not have
the problematic mode of operation described above.  The Buggy Mailer
and the Nonbuggy Mailer receive the same amount of authority (by most
definitions of authority that I am familiar with).  If you are willing to
trust your mailer with enough authority that the Nonbuggy Mailer works,
then you have trusted it with enough authority that the Nonbuggy Mailer
can violate your security goals.

Keep in mind that (in the typical case) we usually cannot reliably
distinguish a Buggy Mailer from a Nonbuggy Mailer.  It is infeasible to
determine whether a given piece of software is bug-free.  Therefore, we
have to make a decision about how must authority to provide the mailer
without knowing whether our mailer is Buggy or Nonbuggy.

This illustrates that your condition may be a necessary condition for
security, but it is not sufficient.