[E-Lang] cap-based design question

[Jonathan S. Shapiro]

> Assume there is exactly one capability per branch.  When a user logs in,
> start a proxy that is the only way the user's process can talk to the
> system.  This proxy can have a table mapping between the name of a branch
> and the capability needed for access....

Unless I have misunderstood, you seem to be proposing a somewhat convoluted
implementation of ACLs. The problem I am wrestling with is not "How do I
think of this in capability terms?". Rather, the problem I am wrestling with
is "Is this really a case where the ACL *model* is the best we can do, and
if so, what might that say about the usability of capability systems in
real, multiuser applications?"

Your proposal seems to be similar in spirit to what MarkM came up with. He
proposed a two-capability system, in which the user (for user, read
throughout "client") holds a capability to a proxy that embeds unforgeably
within its encoding the name of the branch. The proxy in turn is trusted
code, and holds a mapping from these branch names to true branch
capabilities. While we talked over several variations on the theme, in the
end the proxy implemented ACLs. Unless I have misunderstood you, the
distinction between the two proposals, as I see it, lies in the user holding
a name vs. the user holding a capability.

MarkM seems to favor encoding the branch name unforgeably within the
capability because this facilitates selective delegation. At the moment, my
sense is that MarkM's proposal (per-branch capabilities vs. per-branch
names) doesn't actually change things, because the user still needs a means
to enumerate the branches available to them, and at that point the
protections of unforgeability and selective delegation are erased by the
ability to enumerate.

Because the number of branches and working groups grows quickly, I don't see
an alternative to enumeration. We could introduce a level of indirection
through namespaces (each namespace corresponding to a group), but this only
pushes the need for enumeration back one level -- the set of namespaces
itself will change quickly.

Further, we need selective revocation, so in the end, all capabilities must
*logically* point to a proxy. At the moment, the best mechanism I can see
for such selective revocation is to use ACLs (based on crypto keys rather
than user ids, but still ACLs).

> Auditing is an issue I prefer to separate from capabilities.  In e-speak,
we
> had the core (TCB) publish an event on each access to an object.  This
event
> allowed us to track the protection domain (not quite the user) that
> originated the request.  We also allowed the object to use a per-client
> encryption key if it wanted to do its own auditing.  (Actually, we
couldn't
> stop it if we'd wanted to.)

I think that I may have used the term "auditing" in an unfortunate way. For
the moment, it does not appear that our server needs to ever run unconfined
active content, so every transaction on the server runs end to end as part
of a single mutating operation. The rationale for recording the
(cryptographic) identity under which the mutate occurred is to provide a
means of post-hoc recovery from compromised keys.


Still, I'm stuck with my puzzle: surely there is a better tool than ACLs for
approaching this task!  Also, does somebody have a better model than
enumeration?


Jonathan