[cap-talk] non-delegatable authority

ross mcginnis ross_mcginnis at hotmail.com
Sat Jan 19 08:01:04 EST 2008



>From "[cap-talk] Capabilities giving up control? (was: Re: A paper on web-keys)
Jed Donnelley Thu Jan 17 20:17:15 EST 2008"
>...
>The questioner correctly stated about the Object Capability model (somewhat anthropomorphically): "If you have a capability then you can give it to someone else" (that you have a capability to...) 
>The questioner then continued in that vein to note: "That doesn't seem like a good idea. You might want to give someone a capability but not give them the right to pass it on to someone else." 
>It's the same issue again, and again, and again. 
>....


I would just like to comment from an amateur/hobby programmer's point-of-view about the non-delegation issue.

I use to ask the exact same questions as the questioner above.  It does appear to people learning about security and capabilities that being able prevent delegation is an intuitive and necessary ability to have.  I believe you should explicitly explain the reasons why deliberately not having a non-delegatable authority in a high security system is necessary before people even have the chance to ask these types of questions.

As an amateur/hobby computer programmer when I taught myself about capabilities and security and how they work I would relate it to examples of low level security in the day-to-day world.  This is where the main confusion about non-delegation for me arose.  I feel that it is important to point out the difference between the low level security that we use in the everyday world and that of high level computer/computer network security or high level people-people network security.

Perhaps you could point out the difference by saying something like this:

Because security is paramount in any high security computer networks we must always assume the worst case senario will always happen.  For these situations of maximal suspicion we are forced to make the assumption that two entities that can conspire will conspire.  eg: if one can proxy for another to give it unauthorised access than you must assume that it will. You can't allow yourself to form any subjective opinion about how a program is likely to act in a given situation- computer programs don't have a personal character that you can assess.  Because of this there are *never* any situations in the high security world where is it is an advantage to have a non-delegatable authority. The security of a high level system must never be allowed to fail.   If it could fail the consquences may be catastrophic.  There is never any benefit large enough that is given by NDA to outweigh the cost of failure due to the loss of security or the false sense of security that an NDA system presents.

Whereas in contrast, in the everyday low security people-people networks that we build we don't assume that everybody that can conspire will conspire.  We don't assume the worst case but use the most likely case as a guide.  We use the fact that people do have personal characters that we assess.  We also use the fact that conspiracy often comes at a personal cost to the conspirator (eg: it may cost their own time/money and/or the possible loss of reputation/friendship) and hence decide that in these cases the likelyhood conspiracy is reduced.  Because of this there are situations in the everyday people-people network world where it can be an advantage to have non-delegatable authority. The following hypothetical non-delegatable telephone number is an example:  Most people are of such a character that they would not be prepared to proxy for pesky tele-marketing sales people (they are also disinclinded to do it because it costs their time), but they would quite possibly give someone else (such as a tele-marketer) your phone number if politely asked.  I would give such a person an non-delegatable phone number.  Also there are people who in my opinon would be of such character that they would be prepared to proxy for a telemarketer (such as an employee of or one in some other close relation to a telemarketer).  These people I would not give the NDA telephone number to.  Lastly, there would also be the an occassional person who you 'read' wrong and thought that they wouldn't proxy but it turns out that they do.  Because of these sorts of people in this example the low level security system may possibly fail, but it is (hopefully) unlikely.  Overall such a non-deletable phone number system would stop most cold canvas tele-marketing/survey phone calls even though you freely give your phone number to most people.  (You could even give your phone number to an entity who deliberately gives peoples numbers to others-such as a telephone directory company (since they can't pass it on anyway) providing of course you believe that the company would not proxy for people).
Whenever a low security system does fail the consquences should never be possible to be catastrophic.  For a low level security system the advantages gained by deploying NDA may (though not necessarily) outweigh costs involved in failure due to the loss of security or the false sense of security that an NDA system presents. 

Ross


_________________________________________________________________
Your Future Starts Here. Dream it? Then be it! Find it at www.seek.com.au
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Ahet%3Ask%3Anine%3A0%3Ahot%3Atext&_t=764565661&_r=OCT07_endtext_Future&_m=EXT


More information about the cap-talk mailing list