[cap-talk] The Cascade Problem viewed as a Permission vs. AuthorityDistinction

[Karp, Alan H]

Toby Murray wrote:
> 
> The paper puts it like this:
> There is a cascading path from "ibm" on entity A to "hp" on 
> entity B via 
> shared channel  "shell". The assurance rules require an 
> assurance level 
> of at least "overseer" in order to be able to simultaneously 
> access botg 
> "hp" and "ibm" information. However, with a configuration 
> that allows A 
> and B to share "shell" information, entities with an 
> assurance rating of 
> just "consultant" can obtain this access.
> 
We used a similar example to illustrate the features of Client Utility
(CU).  As you point out, you need to consider authority and not just
permission.  

The key here is who will do what.  If Alice (A) extracts part of the
data from HP and inserts it into Shell, then Bob (B) can copy that data
from Shell to IBM.  There are numerous projects that tag data to prevent
just his sort of copying, but I don't know how successful they are if
Alice and Bob want to violate the rules.  However, they may give honest
employees the tools needed to follow the rules.  That's the point of
Voluntary Oblivious Compliance (VOC).

In CU, we had no control over data once it was removed from a file, so
we focused on what we could do to control access to individual files.
In this example, Alice could copy a file from the HP folder to the Shell
folder without worrying that Bob could read it, much less copy it to the
IBM folder.  In fact, Bob couldn't even find out that the file existed,
no matter what folder it was in.  Hence, Alice could be oblvious to the
rules and still follow them.  It was voluntary because Alice could read
the data and insert it into a new file in the Shell folder.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp
  
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Type: text/x-vcard
Size: 433 bytes
Desc: Karp, Alan H.vcf
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20060524/3342d0c6/attachment.vcf