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

[David Wagner]

Toby Murray writes:
>I'm defining authority as "any action that can be performed or caused"
>to occur.

That's probably one important place where we differ.  Maybe we should be
careful and precise about the definition of authority.  As I mentioned
earlier, usually when we talk about "authority", we are using some
abstraction of "authority" under which pure computation does not count as
authority.  Let me call that "the conventional abstraction of authority"
(though I admit that this name is problematic).  As I've mentioned,
the difference between the Buggy Mailer and the Unbuggy Mailer is
purely computation.  Consequently under the conventional abstraction
of authority, the Buggy Mailer and the Unbuggy Mailer have the same
authority.

If you had in mind an authority analysis using a more precise
abstraction of authority, then that runs into the challenge that we
don't know how to measure authority more precisely for complex software
systems.

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

In theory, it could.  In practice, that kind of program analysis is
beyond what we know how to do with any confidence.  Proving that the
Unbuggy Mailer is free of bugs or malicious backdoors is beyond the
state of the art, for any software system of ordinary complexity.

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

You are using the term "definition" where I personally think it would be
better to call it a "design principle" or "rule-of-thumb" or something
like that.  My examples are intended to point out that your principle is
not satisfactory as a general-purpose definition of what it means for a
system to be secure.  Your principle may be a useful guideline.  It may
be a useful basis for analysis that can help to shed light on the
security properties of a system.  However, that does not make it a
definition of security.

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

To apply your criterion we have to know how much authority the
user is willing to give the mailer.  My point is that the user has
to make that determination without knowing whether their mailer is
Buggy or Nonbuggy.