[cap-talk] Capabilities - the rub (was: NCSC TCSEC)

John Carlson john.carlson3 at sbcglobal.net
Thu Nov 9 23:56:46 CST 2006

> Anyway, I think you raise a good point here.  I'm inclined to think  
> that
> there may be an important difference between protecting against  
> malicious
> users vs protection against malicious code.  User-based privilege  
> management
> (uids, ACLs, etc.) seems to do a semi-OK job at the former, but a  
> lousy job
> at the latter.

It's difficult to protect against malicious users on the internet  
any network), where uids, ACLs are practically non-existent--that is,  
it's extremely
easy to get a uid, due to the nature of networks.  What I am saying  
is, it's hard to
protect messaging systems from abuse.  Essentially, you have to give  
each person
you want to communicate with a brand new revocable capability to your  
inbox.  If
you hand out the same revocable capability, you won't know who abused  
it.  And if
someone does abuse it, you're stuck with communicating a new  
capability to everyone
else (but who was the abuser?).  Thus, putting something on a  
business card is not
reasonable, unless you print a new capability on each business card  
(I'm sure the
printers will love you for this).  I think that public key  
cryptography is a better solution
than capabilities here.  But perhaps you could give someone a  
revocable capability to
use your public key.  I could see "encrypt for" and "verify  
signature" methods on this capability,
so the public key could remain hidden behind the capability.  If the  
revocable capability
is shared, you can at least get who signed the message (assuming you  
are sending
non-signed messages and non-verified messages to the junk pile).


More information about the cap-talk mailing list