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

[Toby Murray]

Fred Spiessens wrote:

>
> 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.
>
<snipped most of Fred's reasoning which I really like>

> *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.
>
I really like this interpretation, as it gives a framework to view both 
of the different conclusions that have been drawn from Boebert's proof.

> 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.
>
Interestingly enough, this is exactly how (later on in )CapMyths they 
solve the problem of enforcing the *-property anyway: by building a 
data-diode that allows the low subject to write "int"s (which in E I 
guess are really caps to immutable objects containing integers) but 
nothing else to the high subject. The data-diode is an 
authority-reducing inter-positioned relied-upon subject that gives low 
subject authority to high subject without having authority to delegate 
(anything useful) to high subject.

-- 
Toby Murray
Advanced Computer Capabilities Group
Information Networks Division
DSTO, Australia

IMPORTANT: This e-mail remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the
Crimes Act 1914. If you have received this e-mail in error, you are
requested to contact the sender and delete the e-mail.