[cap-talk] Authority vs. Information Flow

[Toby Murray]

On Sun, 2008-02-17 at 10:43 -0800, David Wagner wrote:
> Toby Murray writes:
> >David Wagner writes:
> >> This is not a possible trace, since you stipulated that Dave's
> >> behavior is fixed and immutable and he will always try to press
> >> the button.
> >
> >Yes. But we don't know *when* Dave will try to press the button.
> 
> Then I think you need to add a notion of time to your model.
> The model is already a bit sketchy without it, and I think you've
> just found a place where it is needed.  Either that, or you've
> found a problem with your "delete from the trace" model of causality.

Not necessarily. Dave may act before, or after Alice. We need to account
for both cases. The current model does this. I'm not convinced that time
is necessary, particularly since in most cases we cannot make reliable
assumptions about the timing of even relatively trusted code.

> 
> >I'll give you one. Let's take the prototypical confused deputy example.
> >Carol is a compiler, Alice is her user and Bill is her billing file.
> >
<snip>

> I don't think this situation is analogous to "Will Bob see the
> light?"  The reason is that the caller of Carol gets to control
> the contents of what Carol writes into the file.

I don't see how this matters. (This obviously hints that I don't
understand your argument. I hope to rectify this.)

>   Therefore, the
> situation where Dave writes and then Alice writes is not equivalent
> to the situation where Dave writes and Alice does not.

But the CSP process I gave didn't model *what* was written to the file.
Hence, it cannot make these sorts of distinctions.

>   Therefore,
> if we model this accurately, I think my definition would say that
> Alice *does* have authority in this situation, even though she
> does *not* have the authority in the "Will Bob see the light turn
> on?" example.
> 
> Also I think to fully model this situation you may need a notion
> of time, and then you might find that Alice does have authority
> because she can control the timing at which the change to the file
> is visible to others.

I hope that we would not need to get into this level of detail to
accurately capture authority.

> 
> However if you set up this situation so that it is exactly identical
> to the "Will Bob see the light turn on example?" then I think we'll
> indeed conclude that Alice has no authority.  For instance, suppose
> we know that the contents of the output file is not visible to anyone
> until time T (no matter when it is written), suppose we know that
> Dave will always call Carol.Execute(Bill) before time T, suppose
> that the caller of Carol cannot control what is written to the file,
> suppose the file keeps no record of when or how many times it is
> written, and suppose that Alice's access to Bill is revoked at or
> before time T.  In that kind of crazy situation, I think we could
> indeed (under my definition) conclude that Alice does not have authority
> to modify the contents of the file -- and I think that conclusion
> would be safe.

I still don't agree. 

Let me try to draw some high level conclusions from this. Hopefully it
will shed light on the fundamental point at which our intuitions
diverge.

>From what I gather you're saying:

In a system of Alice and Bob, Alice can affect Bob (via the light).

In a system of Alice, Dave and Bob, Alice can no longer affect Bob (via
the light) because the scenarios in which she does, and does not, act
cannot be distinguished (by Bob).

The fundamental problem I have here is that the addition of a another
subject that cannot affect Alice in any way has *reduced* her
authority. 

Let's assume that neither Alice nor Dave should be able to cause Bob to
see the light turn on -- that Bob seeing the light turn on is a "bad"
thing, Now this "bad" thing can be precipitated (weasel word to avoid
saying "caused") by both Alice and Dave, since Alice and Dave can both
push the button. By your definition, we would conclude that this system
is still secure, since neither of them can cause the light to turn on.
But the system is not. Neither should be able to make Bob (be able to)
see the light when he otherwise wouldn't have.

Arguing that "It's OK that Alice can push the button and cause Bob to
see the light, since Dave would have anyway" doesn't solve the problem,
since we want neither Dave nor Alice to be able to cause Bob to see the
light.

Hence, I argue that your definition may underestimate authority.

Just because I'm choosing (here) to specify Dave's behaviour, does not
necessarily mean he is trusted to be able to turn the light on.
Similarly for Alice.

I can't help feeling that with your definition that there may be cases
when we underestimate a subject's authority.

(The fact that our intuitions disagree -- that I believe that even in
the first light example that both Alice and Dave should rightly be
considered to have authority to cause Bob to see the light -- doesn't
help here but I'm trying to look past that, perhaps not as successfully
as I might like.)


> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk