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

[Toby Murray]

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

Absolutely. But I'm finding that I can, to some degree, reason about
authority for small CSP models. I hope that this is a first step in this
area.

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

Indeed.

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

I see your point. 

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

Indeed. In either case, however, the user would be unhappy were the
mailer to have the (behaviour and) ability to insert "not" into the
user's message or otherwise corrupt its meaning. When analysing a model
of the mailer, what I care about, then, is whether the behaviour
represented by the model allows the mailer to acquire authority that
exceeds that which the user is willing to trust it with -- i.e. whether
in the model (which is assumed to capture all possible behaviours of the
relevant mailer) the mailer can perform or cause the user's message to
be corrupted.