[E-Lang] cap-based design question
Jonathan S. Shapiro
shap@eros-os.org
Wed, 29 Aug 2001 23:52:02 -0400
This is a multi-part message in MIME format.
------=_NextPart_000_003B_01C130E5.999DBC60
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
This may belong on cap-talk, but since a lot of people here have been in =
on related discussions...
Mark Miller and I have been discussing a naming issue for PCMS. On first =
examination it appears to be an example where capability-based =
protection yields undesirable complexity. It is possible that I have =
stumbled into a motivating case for split capabilities.
With apologies for length, I need to put some context on this.
PCMS is a scalably distributable configuration management system that we =
are working on in the lab at Hopkins. It uses cryptographic hashes of =
content as names for immutable objects, and strongly random numbers =
(plus scoping) for mutable objects. Branches are an example of a mutable =
(appendable) object, so I shall use these as an example here.
In PCMS, branches are cheap to create. The anticipated mechanism for =
disconnected development is to commit to a local (on the laptop) branch =
and then merge when reconnected. This means that a project will, over =
time, come to have thousands of branches.
The sheer number of branches strongly argues that some form of "group" =
mechanism is needed. The problem here is that when a new person joins a =
project it is exceedingly painful to generate for them new capabilities =
for each of these thousands of objects. Similarly, when a person leaves =
a project, revoking thousands of keys is quite a nuisance. The goal of =
revocation here is (a) to prevent a party using this authenticator from =
making subsequent modifications, and (b) to prevent future read-only =
disclosures due to failures on the part of this user to safely manage =
their authentication keys.
Either a per-(client,object) capability or a per-client session key is =
needed, because an auditing function is also required. We need to be =
able to identify the cryptographic key under which each commit was made, =
so that if that key becomes compromised we can re-examine everything =
done with it.
The audit issue means that we really want to discourage human delegation =
in this system. While we recognize that this is unenforceable (a user =
can always give away their key), our feeling is that a small core of =
developers who act as "gatekeepers" can be reasonably educated about =
safe hex (i.e. responsible key handling). We also feel that in this case =
fine-grain authority may work against the user psychology, because it =
encourages the idea that partial delegation (which partially defeats =
auditing) might be an okay thing to do.
In short, we seem to be coming to a system in which some form of =
not-quite-user identity is desirable. The identity is of the crypto key, =
not the user, but that's enough for recovery audits.
The question then becomes: given that the system must be able to =
enumerate for the user all of the outstanding branches that this =
authenticator is permitted to access, and that any software agent that =
can connect and authenticate can therefore enumerate the total set of =
branch capabilities, is there any real benefit to using per-branch =
capabilities at all? That is, might this be a situation where ACLs are =
actually a more appropriate mechanism?
Finally, I want to say here that MarkM and I were able to model the =
semantics I thought we wanted in terms of capabilities that are (object =
id, swiss number) pairs. The issue at hand is not whether capabilities =
have adequate expressive power. The issue is rather that the disclosure =
model of the application seems to defeat the designative restrictiveness =
of capabilities, and that once this restrictiveness is loss one appears =
to be reduced to ACL semantics in any case and one might as well use a =
straightforward implementation.
This probably isn't very clear, but I'ld be happy to try to clarify =
further. Any reactions?
Jonathan
------=_NextPart_000_003B_01C130E5.999DBC60
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>This may belong on cap-talk, but since =
a lot of=20
people here have been in on related discussions...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Mark Miller and I have been discussing =
a naming=20
issue for PCMS. On first examination it appears to be an example where=20
capability-based protection yields undesirable complexity. It is =
possible=20
that I have stumbled into a motivating case for split =
capabilities.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>With apologies for length, I need to =
put some=20
context on this.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>PCMS is a scalably distributable =
configuration=20
management system that we are working on in the lab at Hopkins. It uses=20
cryptographic hashes of content as names for immutable objects, and =
strongly=20
random numbers (plus scoping) for mutable objects. Branches are an =
example of a=20
mutable (appendable) object, so I shall use these as an example=20
here.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>In PCMS, branches are cheap to create. =
The=20
anticipated mechanism for disconnected development is to commit to a =
local (on=20
the laptop) branch and then merge when reconnected. This means that a =
project=20
will, over time, come to have thousands of branches.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The sheer number of branches strongly =
argues that=20
some form of "group" mechanism is needed. The problem here is that when =
a new=20
person joins a project it is exceedingly painful to generate for them =
new=20
capabilities for each of these thousands of objects. Similarly, when a =
person=20
leaves a project, revoking thousands of keys is quite a nuisance. The =
goal of=20
revocation here is (a) to prevent a party using this authenticator from =
making=20
subsequent modifications, and (b) to prevent future read-only =
disclosures due to=20
failures on the part of this user to safely manage their authentication=20
keys.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Either a per-(client,object) capability =
or a=20
per-client session key is needed, because an auditing function is also =
required.=20
We need to be able to identify the cryptographic key under which each =
commit was=20
made, so that if that key becomes compromised we can re-examine =
everything done=20
with it.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The audit issue means that we really =
want to=20
discourage human delegation in this system. While we recognize that this =
is=20
unenforceable (a user can always give away their key), our feeling is =
that a=20
small core of developers who act as "gatekeepers" can be reasonably =
educated=20
about safe hex (i.e. responsible key handling). We also feel that in =
this case=20
fine-grain authority may work against the user psychology, because it =
encourages=20
the idea that partial delegation (which partially defeats auditing) =
might be an=20
okay thing to do.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>In short, we seem to be coming to a =
system in which=20
some form of not-quite-user identity is desirable. The identity is of =
the crypto=20
key, not the user, but that's enough for recovery audits.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The question then becomes: given that =
the system=20
must be able to enumerate for the user all of the outstanding branches =
that this=20
authenticator is permitted to access, and that any software agent that =
can=20
connect and authenticate can therefore enumerate the total set of branch =
capabilities, is there any real benefit to using per-branch capabilities =
at all?=20
That is, might this be a situation where ACLs are actually a more =
appropriate=20
mechanism?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Finally, I want to say here that MarkM =
and I were=20
able to model the semantics I thought we wanted in terms of capabilities =
that=20
are (object id, swiss number) pairs. The issue at hand is not whether=20
capabilities have adequate expressive power. The issue is rather that =
the=20
disclosure model of the application seems to defeat the designative=20
restrictiveness of capabilities, and that once this restrictiveness is =
loss one=20
appears to be reduced to ACL semantics in any case and one might as well =
use a=20
straightforward implementation.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>This probably isn't very clear, but =
I'ld be happy=20
to try to clarify further. Any reactions?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Jonathan</FONT></DIV></BODY></HTML>
------=_NextPart_000_003B_01C130E5.999DBC60--