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

[Toby Murray]

On Tue, 2007-09-18 at 02:40 -0700, David Wagner wrote:
> 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.

Aha. Perhaps you've uncovered another of my unintentionally unstated
assumptions.

I'm defining authority as "any action that can be performed or caused"
to occur.

Hence, an analysis of the Buggy Mailer would reveal that it has more
authority than the Unbuggy Mailer, since the former can do stuff (insert
the "not") that the latter cannot. Hence, assuming we trust neither of
them to be able to insert the "not", the former can be considered
insecure while the latter considered secure.

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

True. However, I'm applying this definition to models of software.
Without a means to autmoatically produce correct models from code, I am
(at the moment) having to live with the fact that the models themselves
might be inaccurate representations of the real systems. However, this
is orthogonal to the techniques I'm trying to develop (which are a means
to reason about authority in (presumed accurate) models of software).

> 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 is different to the problem I'm trying to solve. I'm not trying to
decide how much authority to give the mailer, nor come up with a scheme
for doing so.
I'm trying to decide, given a system in which the mailer has already
been given permissions P, and given the (presumed accureately specified)
behavior of each entity in the system, and given how assumptions about
how much the user is willing to trust the mailer, is the system insecure
(i.e. does the mailer's actual authority exceed the authority with which
the user is willing to trust it?)

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

Does this last comment still apply in light of the (what are hopefully)
clarifications above?