R.e. DCCS as first proposed distributed capability protocol: I also didn't then, and still don't, know of any earlier work on this. If there were any I think I would have run across it. It's probable that Norm (or even I) envisioned distributing capabilities this way earlier, but we didn't work out the scheme for collapsing multiple indirections, and we didn't publish.
At 11:39 AM 4/29/2004, Charles Landau wrote: >R.e. DCCS as first proposed distributed capability protocol: > >I also didn't then, and still don't, know of any earlier work on this. If >there were any I think I would have run across it. It's probable that Norm >(or even I) envisioned distributing capabilities this way earlier, but we >didn't work out the scheme for collapsing multiple indirections, and we >didn't publish. I'm not sure if the date might be significant to anybody, but the first publication on this topic was an LLNL report: J. E. Donnelley, "DCAS" - A Distributed Capability Access System, Lawrence Livermore Laboratory Report UCID-16903, August 1975. that was substantively identical to the later DCCS publication: J. E. Donnelley, A Distributed Capability Computing System, Proceedings of the Third International Conference on Computer Communication, August 1976, pp. 432-440. http://www.webstart.com/jed/papers/DCCS/ Since that first LLL report was my first publication I'm sure it took me some months to get it published. When did you leave LLNL to go work for Timeshare Charlie? Wasn't it in about that time frame (1975)? I know you and I certainly discussed the DCCS (e.g. with regard to the problems passing some RATS capabilities, like file capabilities, that couldn't be emulated with Slave capabilities). Was that discussion after you left LLNL? I'm a little surprised you weren't a co-author on the DCCS paper.(Continue reading)
(Responding to Jed Donnelley's remark that there is essentially no value added by the ability of one capability to invisibly (that is, undetectably) emulate (I believe the current term is "proxy") another capability.) I too have been impressed with the importance of proxying invisibly, since my days with the PDP-1 at MIT in 1970. I'm aware of the following benefits: 1. Making a program's behavior reproducible (that is, the same with or without proxying) is of use when debugging. One debugging technique is to proxy one or more of a program's capabilities to monitor and/or control the program's use of its capabilities. While most practical programs have many sources of irreproducibility, we attempted to control them in the PDP-1 and in KeyKOS/370. Seemingly innocuous (from a purely security standpoint) functions such as getting the time of day fall into this category. These provide mechanisms for covert channels, as well as being just annoying when debugging. I grant that a well-behaved program should not be trying to detect proxying. But a program under debug is by definition not well-behaved. Even if we can't control all sources of irreproducibility (due, for example, to architectures such as S/370 in which the read clock instruction was unprivileged), shouldn't we do our best? 2. Consider for example a client and a server. The two parties have a contract that states that if the client behaves in a certain manner(Continue reading)
At 01:43 PM 4/29/2004 Thursday, Jed Donnelley wrote: >I'm particularly curious to know about any 'modern' implementations of mechanisms to share descriptor or data based capabilities across a network - e.g. to compare them with earlier concepts and to see how they compare. Might anybody have any pointers? Might there be any sort of index of such concepts and/or implementations? There's a bare start at: http://c2.com/cgi/wiki?PasswordCapabilityModel http://c2.com/cgi/wiki?DistributedObjectCapabilityModel See also: ftp://ftp.digital.com/pub/DEC/SRC/publications/wobber/sno.ps ftp://ftp.cs.vu.nl/pub/papers/amoeba/dcs86.ps.Z And, of course, CapTP at http://www.erights.org/elib/distrib/captp/ and the Web Calculus at http://www.waterken.com/dev/Web/Calculus/ >If not I might take some time to work on such an index. I hope you do! Such an index would be very valuable. -- -- Text by me above is hereby placed in the public domain Cheers, --MarkM
At 1:43 PM -0700 4/29/04, Jed Donnelley wrote: >When did you leave LLNL to go work for Timeshare Charlie? Wasn't it >in about that time frame (1975)? I know you and I certainly >discussed the DCCS (e.g. with regard to the problems passing some >RATS capabilities, like file capabilities, that couldn't be emulated >with Slave capabilities). Was that discussion after you left LLNL? >I'm a little surprised you weren't a co-author on the DCCS paper. > >Norm, when did you start work on capability based systems? I'd be >interested to hear the story of how you and Charlie started working >together on such systems. In September 1967 I enrolled in MIT and soon connected with the PDP-1 system where the ideas in Dennis and van Horn's seminal paper [1966] were being implemented. I am fortunate to have learned about capabilities before my mind was poisoned with more conventional systems. In September 1972 I left MIT and went to the RISOS group at LLNL, as you know. While there I met Norm when he gave a lecture about his work on KeyKOS (then Gnosis). Yes we discussed the DCCS, but I think the main idea of collapsing indirection chains, and all the writing, were yours. Around September 1976 I left LLNL and went to work with Norm at Tymshare, where we built KeyKOS.
<this message is a continuation of a thread that was started off the cap-talk list. I hope that the earlier context will be posted to the archive soon> At 03:54 AM 4/29/2004, Jonathan S. Shapiro wrote: >On Wed, 2004-04-28 at 12:30, Jed Donnelley wrote: > > > However, if a subject is a process then I certainly think > > the notion (as I understand it above) of "safety" can be enforced in an > > access list based system. Namely, the server of the resource (who > > knows who has access) can simply deny any request to add a process > > to an access list unless the requesting process is on the access list. > > > > Not so? Am I missing something there? > >Yes. You are ignoring the 'own' right. One of the defining >characteristics of an ACL system is that the holder of the own right can >arbitrarily assign rights to others. Any server that doesn't honor this >isn't implementing the ACL model. And presumably a process without the "own" access right is not allowed to assign the right to others - directly. This property violates what I and my colleagues termed the "inalienable right to communicate access": http://www.webstart.com/jed/papers/Managing-Domains/#s6 In my opinion such an effort at a "right" is nonsense. It simply forces processes who wish to share rights to do so inefficiently by proxy. I argue that any such effort is counterproductive. If the only additional value in the capability model was something to(Continue reading)
At 02:55 PM 4/29/2004, you wrote: I argue that there are so many such processes that such >communication may as well be open. That is, the file server >must protect itself (as best it can) from resource consuming >denial of service attacks anyway - to protect from >the processes that legitimately have file capabilities. >If a person (or process) wants to launch a denial of service >attack, it isn't going to be limited from doing so by its >inability to obtain a file (or other) capability. > >Believing that communication limitations will protect >against such attacks is what I see as "silly." I at least >see this denial of service protection issue as secondary >to the issue of directly protecting against resource access. > >Can we agree on that much? > >--Jed http://www.nersc.gov/~jed/ I very briefly took the exact same stance (less articulately) recently in an offlist email exchange with JAR, in the context of adding the E eventual-send model to scheme48. Covert channels seem to me to be among the least of our problems in our current world of buffer overflow ridden C code, ACL's and out-of-the box defaults that are utterly ridiculous. -David Mercer Tucson, AZ(Continue reading)
At 01:51 PM 4/29/2004, Charles Landau wrote: >(Responding to Jed Donnelley's remark that there is essentially no value >added by the ability of one capability to invisibly (that is, >undetectably) emulate (I believe the current term is "proxy") another >capability.) > >I too have been impressed with the importance of proxying invisibly, since >my days with the PDP-1 at MIT in 1970. I'm aware of the following benefits: > >1. Making a program's behavior reproducible (that is, the same with or >without proxying) is of use when debugging. One debugging technique is to >proxy one or more of a program's capabilities to monitor and/or control >the program's use of its capabilities. > >While most practical programs have many sources of irreproducibility, we >attempted to control them in the PDP-1 and in KeyKOS/370. Seemingly >innocuous (from a purely security standpoint) functions such as getting >the time of day fall into this category. These provide mechanisms for >covert channels, as well as being just annoying when debugging. > >I grant that a well-behaved program should not be trying to detect >proxying. But a program under debug is by definition not well-behaved. > >Even if we can't control all sources of irreproducibility (due, for >example, to architectures such as S/370 in which the read clock >instruction was unprivileged), shouldn't we do our best? I'm finding it interesting to review some of these early debates. I hope others aren't bored.(Continue reading)
At 02:30 PM 4/29/2004, Mark S. Miller wrote: >At 01:43 PM 4/29/2004 Thursday, Jed Donnelley wrote: > >I'm particularly curious to know about any 'modern' implementations of > mechanisms to share descriptor or data based capabilities across a > network - e.g. to compare them with earlier concepts and to see how they > compare. Might anybody have any pointers? Might there be any sort of > index of such concepts and/or implementations? > >There's a bare start at: >http://c2.com/cgi/wiki?PasswordCapabilityModel >http://c2.com/cgi/wiki?DistributedObjectCapabilityModel Thanks! I'd like to inject a question (discussion?) about something said in the above with regard to the "password-capability system". Namely, "Cryptographic capability protocols, by themselves, can never be more than password capability systems". If the above statement is true then it would seem I've been fooling myself by considering some of the protocols in: http://www.webstart.com/jed/papers/Managing-Domains/ in particular: http://www.webstart.com/jed/papers/Managing-Domains/#s13 that was the primary reason for publishing that paper. With a scheme along these lines, while it is still true that it depends on the inability to guess a string of bits, at least it is set up so that the string of bits(Continue reading)
At 02:55 PM 4/29/2004 Thursday, Jed Donnelley wrote: ><this message is a continuation of a thread that was started off the cap-talk >list. I hope that the earlier context will be posted to the archive soon> I hope so too. It's a great discussion! Thanks to Norm Hardy and Alan Karp, I believe I have a complete record of the thread. I have asked all who've posted for permission to repost this thread publicly, on cap-talk. No one has refused, but I have not received all the permissions yet. I'll repost as soon as I do. >1. Definition of what you might call an Internet capability model. This >could be something along the lines of: > >http://www.webstart.com/jed/papers/Managing-Domains/#s13 > >though I think modern encryption technology would suggest a >rework. The basic idea would be to define a protocol for sending >blocks of bits that: > > a. Can securely represent the right to do anything that a service > (server) process might chose to make available. > > b. Can be communicated securely - hopefully without contacting > the service process except of course when it is the source or > destination of the rights communication directly. > > c. Is safe from evesdropping. That is, the form that the capability takes > when it's in, say, a processes memory space or in an email message,(Continue reading)
RSS Feed9 | |
|---|---|
59 | |
12 | |
35 | |
5 | |
70 | |
193 | |
13 | |
2 | |
1 | |
1 | |
3 | |
11 | |
7 | |
25 | |
13 | |
149 | |
33 | |
111 | |
26 | |
31 | |
22 | |
9 | |
85 | |
19 | |
161 | |
114 | |
177 | |
27 | |
36 | |
22 | |
12 | |
6 | |
5 | |
24 | |
16 | |
18 | |
205 | |
156 | |
106 | |
25 | |
93 | |
18 | |
60 | |
278 | |
39 | |
140 | |
296 | |
11 | |
121 | |
210 | |
225 | |
169 | |
75 | |
20 | |
35 | |
389 | |
188 | |
118 | |
31 | |
111 | |
276 | |
401 | |
600 | |
210 | |
130 | |
137 | |
230 | |
97 | |
207 | |
571 | |
316 | |
106 | |
44 | |
68 | |
172 | |
607 | |
757 | |
212 | |
114 | |
24 | |
145 | |
213 | |
215 | |
65 | |
52 | |
14 | |
111 | |
186 | |
303 | |
282 | |
132 | |
28 | |
111 | |
38 | |
44 | |
175 | |
93 | |
304 | |
398 | |
20 | |
306 | |
254 | |
176 | |
133 | |
5 | |
3 | |
7 | |
216 | |
50 | |
1 | |
2 | |
41 | |
1 | |
1 |
