-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/4/2016 7:00 AM, [email protected] wrote: > ... > From: Patrick R McDonald <[email protected]>... > Tahoe-LAFS Weekly News, issue number 56, February 4 2015... > Nuts and Bolts... Friday, 01/29/16... > once you provide another person... a cap, you currently do not have > a reliable method to revoke access to the data associated with that cap...
The 2 biggest weaknesses of a pure capability system are inability to: - - revoke delegated capabilities - - control onward delegation of capabilities That's why "membranes" were invented. The earliest mention I can find is by Mark Miller in 2003: http://www.eros-os.org/pipermail/e-lang/2003-January/008434.html The earliest paper I can find is: "Capability confinement by membranes" Yves Jaradin, Fred Spiessens and Peter Van Roy 2005 MAR 22 We are extending the concept of membrane to an access control agent that can enforce arbitrary policies, starting with simple things like Access Controls Lists (ACLs), the major alternative to capabilities, for the best of both worlds. As we also prefer versioning immutable files to having mutable files, we are using the git-annex remote for Tahoe. So our current work is modifying git-annex to serve as a membrane. That has the beneficial side effect of enabling use of human meaningful identifiers (git repo paths) when talking to the proxies, while retaining the benefit of unguessable capabilities on the actual underlying resources. I mentioned our early notions on the mailing list back on 2012 MAR 19. Since then, to facilitate standards based interoperability with other policy tools, we have integrated XACML into other parts of our system; now we are working to extend the Tahoe git-annex remote to serve as an XACML Policy Enforcement Point (PEP), that only can exercise Tahoe caps with permission (and help) from a Policy Decision Point (PDP). Thus capabilities are never directly delegated to principals; instead, they are exercised on behalf of those principals by a PEP/membrane. Revocation is handled by changing the ACL in the policy consulted by the PDP. Unauthorized onward delegation is precluded by the PDP denying the PEP permission (and information needed) to act on behalf of anyone not on the ACL in the XACML policy. We plan to formally verify critical PEP and PDP code. When we have more of the pieces integrated, we plan to open source our work, not just to comply with the GPL etc. and be responsible members of the community, but also so others can independently verify it (rather than trust our verification). We would welcome critical analysis of this scheme. - -- Stuart W. Card, PhD: VP & Chief Scientist, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 <[email protected]> www.critical.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAla4EDkACgkQS7PQ0a2weL7q2QCfc1HBMHH4DQxP6nC8o3y9k5g4 rx0AnieaBHaBi3GKH9Zw1AWfvZlHIYPI =xQL+ -----END PGP SIGNATURE----- _______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
