[cap-talk] Authority is always potential (was: Re: Reinterpreting POLA...)

[Mike Samuel]

On 19/09/2007, Jed Donnelley <jed at nersc.gov> wrote:
>
> On 9/19/2007 12:29 AM, Toby Murray wrote:
> > On Tue, 2007-09-18 at 13:42 -0700, David Wagner wrote:
> >> Toby Murray writes:
> >>> Indeed. In either case, however, the user would be unhappy were the
> >>> mailer to have the (behavior and) ability to insert "not" into the
> >>> user's message or otherwise corrupt its meaning. When analyzing a
> model
> >>> of the mailer, what I care about, then, is whether the behavior
> >>> 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 behaviors of
> the
> >>> relevant mailer) the mailer can perform or cause the user's message to
> >>> be corrupted.
> >> Got it.  Now I understand where you are going.  It makes sense.
> >>
> >> Your final (nicely worded) paragraph illustrates a confusion of my own.
> >> You point out the distinction between ability and behavior.  The
> ability
> >> of the mailer is independent of its code and is determined by things
> like
> >> what capabilities it is provided with, what restrictions the underlying
> >> platform or OS enforce, and the behavior of other entities that it
> >> interacts with.
>
> Hmm.  I appreciate the struggle you seem to be having with terms
> here, with DavidW using "ability" for what Toby later seems to
> refer to as "potential authority".
>
> DavidW:
> >> The behavior of the mailer depends on the code of the
> >> mailer as well as on its ability.  When we talk about the authority
> that
> >> the mailer has, do we mean to take its behavior into account, or only
> >> its ability?  I am used to thinking about the authority of an entity
> >> only in terms of that entity's ability, not its behavior.
>
> I'm completely with David on this one in that for me the
> "authority" of an executing program is determined by
> its environment and is what DavidW refers to above as
> its "ability" (which I think is an unfortunate term for
> this meaning) and what Toby refers to below as the
> "potential authority" (also unfortunate in my opinion)
> of the executing program:
>
> > There is a very real distinction between "potential" authority and
> > "actual" authority. Potential authority should always be a superset of
> > actual authority.
>
> I call this simply the 'authority' of the executing
> program.  I believe this is the common usage and hope
> we can agree on this.
>
> > One can compute potential authority of an object by making no
> > assumptions about its behavior and, therefore, modeling the object to
> > exhibit all legal possible behaviors.
>
> That is why reasoning about the authority (not 'potential
> authority' or 'ability') of an executing program is so useful.
>
> I hope this isn't a tangent, but of course it's also
> important to consider the input to an executing program
> when consider the range of its possible behavior.  For
> example, a program might be an interpreter of some sort
> (e.g. common scripting languages) where the range of its
> behavior can vary widely depending on what input it
> receives (what script it is asked to execute).  In
> such a case I would guess that Toby would say that the
> executing program's 'actual' authority may be driven by
> its input to closely approach its 'potential' authority?
> Similarly input like a buffer overflow may affect the
> behavior of a program in whatever authority environment
> it might find itself.
>
> I consider an executing program's potential authority
> simply its 'authority', and its 'actual' authority as
> that part of its authority that it exercises in any
> situation.  I don't have a term for what one might consider
> a reasoned limit on that part of a program's authority
> that it may be able to exercise based on its coding.
>
> I understand that Toby is focusing on reasoning about
> the potential behavior of programs from knowledge about
> the program code:
>
> > Often, I think the choice of whether to try to model potential or real
> > behavior (which will lead to computing potential or real authority,
> > respectively) will be based on how much one knows about the software
> > they are modeling.
>
> For example, if one has the program:
>
> halt;
>
> it's safe to assume that no matter what authority it
> is executed with and what input it is given, it will
> not exercise any of its authority.
>
> > Suppose we had some magical means to produce CSP models from real code,
> > such that the model produced was guaranteed to exhibit all possible
> > behaviors of the code. Suppose further we have some abstraction that
> > has been coded and we want to reason about its properties. We can derive
> > the (accurate) CSP model from the code and then reason about the actual
> > authority of internal entities that make up the abstraction.
> >
> > But now suppose we want to know how that abstraction affects the
> > authority of the objects, o,p,q,... with which it is composed. Then the
> > correct thing to do, imo, is to model o,p,q so as to exhibit all
> > possible legal behaviors, within the constraints of the model and the
> > behavior of the abstraction. Now we're reasoning about potential
> > authority.
>
> Can we please stick to referring to the 'potential' authority
> of the executing program as its 'authority' (e.g. much as we
> do with a person) and use some other term or terms to express
> constraints on the program's behavior that may arise from the
> coding of the program?


If you're already reasoning about programs statically, then maybe talk about
"reachable" authority.

If you assume that a program's codebase includes not just it's code, but all
the files, syscalls, networking libraries, and external services that it can
interact with.  Then you can argue about whether it can access /etc/passwd
becomes a question of whether the set of values that reach fopen includes
"/etc/passwd".

The term reachable also arises when doing state-based reasoning.  You use
your possible inputs to come up with a set of initial states, and then you
argue about which states are reachable from that set of initial states.



I admit that I don't know what term to use for any such
> constraint (independent of the program environment which
> defines its "authority" and it's inputs), perhaps others do,
> but I hope it doesn't involve the use of the term "authority".


--Jed
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070919/673d072f/attachment-0001.html