(Brock) did an interview with Ann Hardy of Tymshare? Wow, I need to go find that, right now! This was deeply enlightening, so glad we've got this available to dig into. Lampson discusses capability theory for a few minutes from about 1:05:30, and this has helped me to put into perspective why he has been critical of capability systems. I'm going to break some of this down if anyone wants to digest it. First: the background. Lampson was on Howard Stergis' CAL-TSS project at University of California at Berkley, building a capability-based time-sharing operating system for the CDC 6400. He points out that this wasn't the first such project, that Jack Dennis (and Earl Van Horn) had designed the Supervisor at MIT in 66. Here is Lampson describing capability theory in the interview, slightly edited for clarity: "But it is a very appealing idea - most of the bugs that appear in programming are shown because some part of the program runs outside of the boundaries of what it's supposed to do, it tramples on data that belongs to some other part of the program, and it should never have gone there. So the whole idea of capabilities is to make it either very difficult or impossible by constraining what parts of the state the program can manipulate at any given point - and the difficulty with that idea is that it means that you have to plan out very carefully what parts of the state the program needs to touch. If you want to be hard-nosed about it, so that you can be confident that it's impossible for the program to escape its boundaries; you have to have a very clear idea of what it is you're trying to accomplish. And usually, you don't have such a clear idea. So the result is that the program is getting much harder to write, because the standards are much higher. Typically, people have found that the game isn't worth the candle." His statement here that "you have to have a very clear idea of what it is you're trying to accomplish" is, I think, the most interesting part. It reflects something that current security status quo tends to think about security configuration in general, namely, that security configuration is largely done statically. People go and do their IAM user/group/role/attribute configuration and then walk away, it's not something that is done as a matter of normal operation, such as a user selecting a different file from a file-picker dialog box, which is how the capabilities community tend to think of security. I think this image of the static nature of security configuration is also reflected in his papers on capabilities. The well-known error in Lampson's paper on the equivalence of capabilities to ACLs comes from the same mischaracterisation. Still, it's not an unpopular characterisation.
(Brock) did an interview with Ann Hardy of Tymshare? Wow, I need to go find that, right now!
This was deeply enlightening, so glad we've got this available to dig into. Lampson discusses capability theory for a few minutes from about 1:05:30, and this has helped me to put into perspective why he has been critical of capability systems. I'm going to break some of this down if anyone wants to digest it.
First: the background. Lampson was on Howard Stergis' CAL-TSS project at University of California at Berkley, building a capability-based time-sharing operating system for the CDC 6400. He points out that this wasn't the first such project, that Jack Dennis (and Earl Van Horn) had designed the Supervisor at MIT in 66.
Here is Lampson describing capability theory in the interview, slightly edited for clarity:
"But it is a very appealing idea - most of the bugs that appear in programming are shown because some part of the program runs outside of the boundaries of what it's supposed to do, it tramples on data that belongs to some other part of the program, and it should never have gone there. So the whole idea of capabilities is to make it either very difficult or impossible by constraining what parts of the state the program can manipulate at any given point - and the difficulty with that idea is that it means that you have to plan out very carefully what parts of the state the program needs to touch. If you want to be hard-nosed about it, so that you can be confident that it's impossible for the program to escape its boundaries; you have to have a very clear idea of what it is you're trying to accomplish. And usually, you don't have such a clear idea. So the result is that the program is getting much harder to write, because the standards are much higher. Typically, people have found that the game isn't worth the candle."
His statement here that "you have to have a very clear idea of what it is you're trying to accomplish" is, I think, the most interesting part. It reflects something that current security status quo tends to think about security configuration in general, namely, that security configuration is largely done statically. People go and do their IAM user/group/role/attribute configuration and then walk away, it's not something that is done as a matter of normal operation, such as a user selecting a different file from a file-picker dialog box, which is how the capabilities community tend to think of security.
I think this image of the static nature of security configuration is also reflected in his papers on capabilities. The well-known error in Lampson's paper on the equivalence of capabilities to ACLs comes from the same mischaracterisation. Still, it's not an unpopular characterisation.
001
22338