capability revocation etc.

[Stuart W. Card]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/4/2016 7:00 AM, tahoe-dev-request at tahoe-lafs.org wrote:
> ...
> From: Patrick R McDonald <marlowe at antagonism.org>...
> 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 <Stu.Card at critical.com> 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-----