Hi,
Not sure exactly how I want to ask this question; i.e., how best to differentiate the examples where X should be allowed vs X should be prohibited.
I have a capabilities based security model. Each capability has "authorizations" associated with it (trying to avoid using the word "capability", again :< ).
These authorizations are defined by the entity that creates the capability based on the "authorizations" that *it* has available to it!
I.e., if I own a resource, I have all of the authorizations conceivable for that resource. I can give all or part of those authorizations to entities (actors) of my choosing.
E.g., if the resource is a file, I could elect to give A, B and C read access to that file and write access only to B and D.
Similarly, if the resource is a mechanism, I might give the ability to move it RIGHT to A, B and D; the ability to move it LEFT to B and C; the ability to power it OFF to only A; etc.
It's important to be able to give subsets of your "authorizations" to others -- that you presumably trust (whatever that means). This allows them to act on your behalf.
E.g., if I have read & write access to a file, I might want to give *read* access to that file (principle of least privilege) to someone who will encrypt it's contents for me (returning an encrypted copy of the file but not altering the original; I trust him enough to *see* the file's contents but not enough to allow him to *alter* them -- to, for example, replace the file with its encrypted form... *I* can do that with my write authorization).
Similarly, I might want to give subsets of my authorizations to several different actors concurrently -- so each can do "whatever" to the resource without requiring me to serialize their accesses to it (multiprocessing)
And, I may also want to *forfeit* my authorizations -- possibly after passing them on to someone else.
OK?
Some of the trickier issues I'm trying to address include:
- "revoking" an authorization that I have previously given to another actor (do I do this asynchronously? synchronously with the other actor's consent/participation? etc.)
- handling intermediaries whose roles are strictly as "pipes" (e.g., imagine transparently imposing an actor between A and B -- call it D -- to allow the transactions between those two actors to be Debugged). D should have no need to invoke any of the authorities associated with any capability passed from A to B. It should be restricted to solely *propagating* the capability. I.e., D can't *hold* that capability but can pass it along.
- as a followup to the above, handling cases where the capability can be held or propagated -- but not *duplicated*. I.e., *you* can access this file; *or*, have someone else do it on your behalf; but it's one option or the other... the capability can't multiply!
The goal here is to allow *most* actors to be untrusted and still minimize the risk they pose to the system, the data and operations it implements, etc.
E.g., I could create a resource called an "email address". I could define operations on that like "send to", "forward to", etc. And, I can choose to make the actual address itself, *opaque*!
So, I can create a capability for this resource that has authorizations for "send to". Perhaps there's even a "send exactly once"! I can now give that capability to an actor and it would be able to send email *to* that address -- yet, never *see* the address itself! So, if it was a rogue agent trying to harvest email addresses from ever device that it was running on, this ability would be thwarted.
To protect against it generating neverending quantities of spam, I might opt to give it the "send exactly once" aauthorization knowing that it's damage/annoyance factor would be thusly limited.
If this actor can pass subset(s) of its capability to others, then it could just spawn another copy of itself, send a copy of the capability to that second instance, generate a piece of spam and
*die* -- knowing it's clone has a valid copy of the "send exactly once" authorization!See where this is going? And, how powerful it can be in providing fine-grained control of resources??
It *seems* like what I really want to do is create a "service" (for want of a better word) that implements these "capability authorizations". I.e., if you want to pass a copy of a capability to another actor, you hand the capability to that service along with the desired target actor and that service examines the capability to see the authorizations that you have been granted for *it*!
"Ah, sorry but I can't perform this action for you because you don't have 'propagate a copy' authorization for this capability!"
[ This is really confusing due mainly to the fact that I'm trying to fabricate terms to address concepts that are very similar but different -- capability, authorization, etc.]Hopefully this makes *some* sense... I'll try to work on a better lexicon.
--don