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

Karp, Alan H alan.karp at hp.com
Thu Nov 30 12:04:19 CST 2006


Jed wrote:
> 
> Hmmm.  You seem to be assuming that all processes communicate with
> something that amounts to a person's identity.  

Audit requires some form of identification.  You say below that you want
to "trace back at least some capability accesses to a person".  Hence,
the audit must ultimately connect a request to a person in order to meet
your goal.

> 								  In
that case it seems
> to me we'd be right back to identity based access control - 
> or at least
> for auditing purposes.  

It's IBAC only if the identity is used to decide whether or not to honor
the request.

>                         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.  

I believe that what I have proposed meets that goal if the process
authenticates the channel with an identity that can be traced back to a
person.

>                                                 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.

The explicit introduction process I described, with Tyler asking Jed to
associate a capability with Bob's communication channel, meets this
goal.

> 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
> 
What I have described is outside the capability model in that my
approach assumes separately authenticated channels.  In a pure
capability system, the capability itself provides all the authentication
needed.  Note that audit is an add-on to access control in ACL systems,
too. 
> 
> 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).
> 
That assumes Jed has some means of identifying Bob independent of Tyler.
If that is the case, then Jed can distinguish a channel used by a
process acting on behalf of Bob from a channel used by a process acting
on behalf of Tyler.

>                                              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).
> 
Authenticated channels meet this goal as long as Jed can identify Bob by
means not provided by Tyler.  Tyler can send Bob the capability he would
use, and Jed can distinguish requests made by Bob from those made by
Tyler.  Tracking the delegations needs an additional mechanism.

_________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories 
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Type: text/x-vcard
Size: 423 bytes
Desc: Karp, Alan H.vcf
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20061130/32101b9b/attachment.vcf 


More information about the cap-talk mailing list