[cap-talk] What Boebert actually proved (was: Confinement Confusion (was: Communicating conspirators))

[Fred Spiessens]

On 18 Jul 2006, at 05:48, Toby Murray wrote:
>
> Karget's work also argues that we need to restricted delegation in  
> order
> to achieve "confinement" (the *-property). It cites Boebert here
> erroneously I think because  Boebert's argument doesn't rely on
> unrestricted delegation but instead relies upon having no distinction
> between caps and data.

I've be wanting to give my two cent meaning for some time about how
http://www.erights.org/elib/capability/duals/myths.html
treats Boebert.
I think Karge has chosen the most probable interpretation of  
Boebert's proof, and, just like Boebert, is "only" confused by the  
difference between permission and authority.

I will not go into the difference between the *-property and  
confinement in this mail.

Boebert says : "In capability systems, every permission to exercise  
access carries with it a permission to delegate".
Crucial is where he uses this idea in his proof:  "The program places  
RW_low_object  in low_object"
-  "the program" is the adversary with low clearance,
-  "RW_low_object"  is  that adversary's Read-Write capability to a  
low-confidentiality file, and
-  "low_object" is that low-confidentiality file.

Depending on the interpretation of that sentence, he makes either one  
of the following mistakes:

1) Since low_object is a file,  "places" can be interpreted as  
"writes", and then he made an error right here: forgetting that  
capabilities are unforgeable and can therefore not be data and thus  
not be written to a file.  (I have more to say about this.)

2) "places" is interpreted as "delegates". This interpretation should  
have our preference, because he is arguing that "a permission to  
exercise access should not carry with it a permission to delegate".  
He definitely assumes that capabilities work like this: all of  
Alice's  capabilities-to-target-Bob give her the authority to  
delegate any of her capabilities-to-target-whomever to Bob.
	2a) It is possible that he makes this assumption on false grounds,  
and then this mistake can be explained as  confusing authority with  
permission. In Object-Capabilities we have only one right  
(permission) : access-permission, and it comes with NO guaranteed  
MINIMAL authority (e.g. Bob has still access to the Caretaker after  
revocation of his authority to Carol). If you forget that, you may  
confuse the true fact: "delegation never needs any permissions beyond  
access", with the false idea:  "all access provides you with the  
authority to delegate".
		There are grounds for this confusion, in the fact that some  
capability systems have (only) capabilities-with-guaranteed-minimum- 
authority. These can be modeled by Take-Grant systems.
	2b) But it is also possible that he is talking exactly about  
imaginary "capability systems" that actually work like this.  These  
would be modeled by take-grant systems that combine every write-right  
with a grant-right to the same target. (In that case he would still  
be mistaken, because his example also assumes, without explicitly  
stating it, that every read-right is combined with a take-right to  
the same target too.)

Thus Boebert's proof actually proves this:
If  write-capabilities guarantee grant-authority and read- 
capabilities guarantee take-authority,  then the *-property cannot be  
guaranteed by a simple clearance-level based policy to hand out read- 
capabilities and write-capabilities.

That is TRUE, but:
- not relevant for object capabilities because "access", the only  
permission, comes with no guaranteed authority. All authority stems  
from collaboration, completely mediated by the behavior of both  
invoker and responder. It is enough that one of them has suitably  
restricted behavior (It may not always be easy to find such suitably  
restricted behavior, and to prove that it is suitably restricted, but  
in the *-property case it is really simple: interpose a data-diode)
- not relevant for capabilities that have separate "take" and "grant"  
permissions.

It is somewhat more relevant for capabilities-as-unguessable-data,  
because write-authority to a file, followed by subsequent read- 
authority to that file would amount to delegate-authority.  In that  
case one has to:
- either make sure that capabilities come with no guaranteed  
authority (mediation by both behaviors, like object capabilities)
- or don't use a simple clearance-level based policy to hand out read- 
capabilities and write-capabilities (this may complicate things of  
course)

The solution simply follows from the strong preconditions of what  
Boebert really proved :
=> Avoid that all read and all write authority is carried by  
capabilities that guarantee delegation authority.
	o for instance, use access-permission-only Object-Capabilities like  
in E: they can easily provide as little as zero guaranteed authority.
	o or use Take-Grant capabilities that have no delegation-authority  
guaranteed by any other capabilities than take- or grant-capabilities  
themselves. (The normal Take-Grant systems will do just fine).
	o if you use capabilities-as-unguessable-data, find a way to  
distinguish authority-to-write-plain-data form authority-to-write- 
capabilities-as-data. In many cases that can be feasible (e.g.  
compete behavior mediation).

  In http://www.erights.org/elib/capability/duals/myths.html#confine
it is argued that:
"To prevent Alice from delegating to Bob, don't give Alice access to  
Bob."
"A subgraph of cooperating objects cannot delegate to Bob if Bob is  
not reachable from that subgraph"
--> This ALSO confuses permission with authority: Alice should get  
authority to Bob without getting authority to delegate to Bob.
--> Preventing  that Bob becomes indirectly-connected-in-the-access- 
graph to Alice, cuts of ALL of Alice's authority-to-Bob.
--> The solution is always in the authority-reducing behavior of a  
suitably inter-positioned relied-upon subject.

-------
Fred Spiessens
Research Scientist Secure Software at
Cork Constraint Computation Centre
http://4c.ucc.ie/~fsp


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20060718/b00689eb/attachment-0001.html