[cap-talk] - Karp - Capabilities - tracking responsibility (Was: Bellizzomi - Users in object/capability systems (was: MLS gone bad, Lampson))

Jed at Webstart donnelley1 at webstart.com
Wed Nov 29 17:21:44 CST 2006


At 09:46 AM 11/29/2006, Karp, Alan H wrote:
>Jed wrote:
> >
> > Since I'm not following this fully (I hope we get to discuss it soon),
> > let me just ask:  It's easy to see in the above how Tyler can revoke
> > Bob's use of the permission.  However, can some third party (e.g.
> > an auditor) distinguish accesses by Bob from those by Tyler in
> > such a way as to exonerate Tyler from any actions performed
> > by Bob?  In that case I'll be interested to hear more how that works.
> >
>Depends on what you mean by third party.

By a "third party" I mean an auditor looking at the access logs
for the server of the object.

>Tyler connects to Jed's
>machine over authenticated channel A.  Bob connects to Jed's machine
>over authenticated channel B.  The owner of Jed's machine, the third
>party, knows which channel each request came over.  Hence, the auditor
>can distinguish requests made by Tyler from those made by Bob.

Hmmm.  You seem to be assuming that all processes communicate with
something that amounts to a person's identity.  In that case it seems
to me we'd be right back to identity based access control - or at least
for auditing purposes.  What I'm looking for is a means to allow processes
to interact with nominal (dare I say 'traditional'?) capabilities as permission
tokens but still with the ability to trace back at least some 
capabilities accesses
to a person who can be considered responsible.  A single process may have
capabilities from a variety of sources, some traceable to people (perhaps
different people) and some perhaps not.  When a process invokes a
capability it communicates to the server and sends the server it's permission
token - the capability.  That communication may be encrypted and may use
an identity, but if so it can only be the identity of the process, 
not an identity
for some person.  Regardless I still want (TCSEC still I believe reasonably
wants) auditing records to be able to trace accesses through delegations.
Such a traceable delegation is at a slightly higher level than a
nominal ('traditional') capability communication where at the end of
the communication two processes now have the exact same capability,
but such a higher level traceable mechanism can be built on top of a
base 'traditional' capability communication mechanism

Perhaps this ties into this distinction between on-line and "off-line"
capabilities (?):

At 11:05 AM 11/29/2006, Mark Miller wrote:

>I just talked to Alan and we figured out our misunderstanding. Alan
>was referring to E's sturdy references and captp:// URI strings, which
>together are E's "offline capabilities". For these, each E vat does
>indeed maintain a single mapping table as Alan states. However, you
>can't directly send a message to an offline capability, you can only
>derive a live reference from one.
>
>I thought Alan was referring to E's remote live references, to which
>you can send messages. For these, they are encoded as per-connection
>small numbers, as in DCCS, which are looked up in the four tables I
>mentioned.

but if so I'm afraid the tie-in is lost on me.

I can of course understand how there may be capability 'translation' from
one higher level domain to another (e.g. from one OS to another) - e.g. like
DCCS.  Naturally we would hope that any binding to a responsible person
would work across any such translations.  Perhaps this is why the most
natural approach seems to me to keep any record of delegation of responsibility

e.g.  Tyler -> Bob (I tried switching to 'Carol' Alan, but it was too confusing
                            at this point).

in records on the server.  Think of "Tyler" and "Bob" above as the
hashes of their respective public keys if you like - definitely not simple
processes as in the typical Granovetter diagram.  The processes doing
the communication are quite another thing).  To effect such tracking (e.g.
for auditing purposes, though the mechanism can also be used for
selective revocation) it still seems to me that a means must be provided
for Tyler to communicate a permission to Bob in such a way that Bob
receives a capability labeled as Bob's that Tyler was never able to exercise
(invoke).

If you've suggested a means to do so Alan I still haven't followed how it
works.

Regarding:

At 02:07 PM 11/29/2006, Karp, Alan H wrote:
>At 12:24 PM 11/29/2006, Valerio Bellizzomi wrote:
>>...
>>Are we talking about "non-repudiation" here ?
>>
>>val
>No, audit for assigning responsibility.  Non-repudiation assures Jed
>that Bob cannot deny having taken an action that he actually took.
>Audit for assigning responsibility assures Tyler that Jed won't blame
>Tyler for actions taken by Bob, even if Bob uses a capability that Tyler
>gave him.

It is that assigning of responsibility that I've been focusing on - still
keeping in the back of my mind the HP board scandal and combining
it in a bit of mental gymnastics with the TCSEC concerns.  However, I
don't see why the same mechanism can't be used for non repudiation.
Whatever means is provided for "Bob" to assume responsibility for
invocations of his capability (distinct from the one Tyler has/had) I
believe will also suffice for non repudiation.  If Bob is responsible Bob
is responsible.  He can't deny that responsibility.  Even if he's posted
the capability on a public Web site, it's still his responsibility.  Even if
he manages to get somebody else (e.g. Carol) to accept a further
delegation, that delegation is still his responsibility just as the delegation
from Tyler to Bob was Tyler's responsibility.  For all we (the auditor looking
at the servers access logs) know, Carol could be an identity made up
by Bob to try to get somebody else to take responsibility for his actions.
Similarly Tyler could be trying to hide his responsibility.  It's up to
Tyler to show that he responsibly delegated the permission (in it's
delegated capability form) to Bob.  Once that and Bob's identity are
confirmed then the auditor can focus attention on Bob.

In what I can only again weakly refer to as a 'traditional' capability
system (a system not augmented by personal responsibility tracking -
definitely not something that needs to be added at a low [e.g. kernel]
level), when I give a permission to somebody else, at the end of the
process both I and they have the same capability in our "/Home"
directories.  When processes acting on behalf of each of us make
requests of the server of the object, from the server's viewpoint
(and therefore from the viewpoint of the auditor looking at the server's
logs) there is no way to distinguish one access (some process I've
communicated with for a service) from another (some other process
that Bob communicated with for a service).

If there is some means for obtaining this added value built into
either E's on-line or off-line capabilities then I'd like to hear how it
works.  If not then of course some means can be added above
the base capability communication level (as I've suggested), but
whatever that means is we must be able to see the records it
leaves at the server.

--Jed http://www.webstart.com/jed/ 




More information about the cap-talk mailing list