5 ms·

I would put the author in the "doesn't know what he's talking about camp" in regard to capabilities. The same could probably be said regarding the claim that di

by bascule 11y ago

I would put the author in the "doesn't know what he's talking about camp" in regard to capabilities. The same could probably be said regarding the claim that distributed computing works and that maybe we're ok at security now. All of these feel like fields in their infancy. Capabilities are among the few systems that can solve authorization decisions involving three or more principals. Ambient authority systems e.g. systems based on ACLs are inherently broken when dealing with 3 or more principals (see http://waterken.sourceforge.net/aclsdont/ http://waterken.sourceforge.net/aclsdont/): "The ACL model is unable to make correct access decisions for interactions involving more than two principals, since required information is not retained across message sends. Though this deficiency has long been documented in the published literature, it is not widely understood." If you're looking for a place this arises in practice, look no further than the same-origin policy in web browsers, and the complexity of three principal interactions where one principal is a user, another is a web site, and the third is a malicious web site. That's not to say we should abandon the same-origin policy, but we need authorization primitives that seamlessly span multiple principals. Projects like Capsicum are adding capabilities to OSes like Linux and FreeBSD. Cap'n Proto is demonstrating what's possible with a modern implementation of CapTP. I think the need for authorization-centric (as opposed to identity-centric) access control systems is becoming increasingly clear. Capabilities (particularly in the CapTP sense) are one realization of this idea but there are others.

pron 11y ago
I would put your comment in the "doesn't understand what the author is saying" camp. When he says something has "worked" he doesn't mean it has promising working prototypes or has the potential to improve things. He means that the benefits have been very, very clearly demonstrated to be very significant and widely applicable. And "clearly demonstrated" means their impact has been shown in numerous production settings. As this is the case for distributed systems but not for capabilities, the author's categorization seems spot on, even if current work on distributed systems is "broken", when "broken" has its common modern connotation of "has (possibly much) room for improvement".
- bascule 11y ago
  To reiterate, because you missed my original point: The author thinks we're doing okay at security, and capabilities failed. We aren't doing okay at security, and capabilities are still a promising solution. The solutions where capabilities are truly most promising have no embedded competitors. I'm looking at things like SELinux here. Few other solutions (except e.g. Macaroons) are actually capable of making correct authorization decisions in scenarios involving 3+ principals: the competition is broken, and vicariously, so are most authorization systems which try to solve 3+ principal authorization problem correctly. You may as well be arguing that memory safe / garbage collected languages lost to C circa 1995. C is broken and programs written in C will always be full of holes as compared to equivalent programs in memory safe languages just in the same way as authorization systems not built to handle 3+ principals will make wrong decisions. This is why it's 2015 and we're still dealing with CSRF. If you implement SELinux at your job like I do, and have some informed criticism about how Capsicum is unneeded because SELinux is great, I'd love to hear it! But I'm guessing that isn't the case... I am also guessing it's an area the OP is not particularly informed about.
  - pron 11y ago
    > you missed my original point I think you have simply misunderstood what the author is actually saying. He is not saying what you think he is, and I don't think you disagree with him at all. > The author thinks we're doing okay at security Where does he say that? He says, "security still isn’t a first class concern for most programmers", and puts it in the "No" column. > capabilities are still a promising solution. The author doesn't dispute that. In fact, he says nothing about the promise certain technologies hold. In fact, he says: "I’m much more optimistic about research areas that haven’t yielded much real-world impact (yet), like capability based computing and fancy type systems. It seems basically impossible to predict what areas will become valuable over the next thirty years." The article, however, is not concerned with possible solutions, even those that show great promise. It is only and solely concerned with solutions that have been conclusively shown to work well in the field by having a wide applicability and usage in numerous production projects. As capabilities -- so he says and you don't seem to dispute -- aren't there yet (he emphasizes the "yet"), they belong in the "no" column. That they show great promise -- or even maybe contain the only solution to problems we haven't been able to tackle -- bears absolutely no relevance to the issue of whether they "have worked" or not. It is a statement of fact that they haven't yet, and you don't seem to dispute that. Similarly, putting something in the "no" column doesn't mean that something has lost. The author makes that abundantly clear. A no may well turn out to be a yes in time. A no simply means "not yet" (while "maybe" means that it may in fact be "working" now, we just don't have enough information to conclusively say). The article therefore voices no criticism on the validity of certain technologies at all. That, too, the author makes abundantly clear. It is nothing more than a list of those technologies that to this day have (or haven't yet) been conclusively proven to provide significant benefits and wide applicability in the field. Those that only show promise belong in the "no" category. It is an inventory, not a critique. You have no argument (so it seems) either with me or the author. In fact, I have no knowledge on this subject at all: I have no idea what capabilities are, I have never heard of Capsicum (or SELinux for that matter) and have never even worked on security related issue. it was just clear to me that you are responding to criticism that is simply not there, and responding with great force by dismissing the author (who is very well versed in technology), which is rarely a good idea, especially if you don't carefully read what he has to say.
andrewflnr 11y ago
Yeah, all that stuff is why I'm enamored with them :). I didn't know about CapTP, though. I'll have to look at that more closely.

by bascule 11y ago

pron 11y ago

I would put your comment in the "doesn't understand what the author is saying" camp. When he says something has "worked" he doesn't mean it has promising working prototypes or has the potential to improve things. He means that the benefits have been very, very clearly demonstrated to be very significant and widely applicable. And "clearly demonstrated" means their impact has been shown in numerous production settings. As this is the case for distributed systems but not for capabilities, the author's categorization seems spot on, even if current work on distributed systems is "broken", when "broken" has its common modern connotation of "has (possibly much) room for improvement".

bascule 11y ago
To reiterate, because you missed my original point: The author thinks we're doing okay at security, and capabilities failed. We aren't doing okay at security, and capabilities are still a promising solution. The solutions where capabilities are truly most promising have no embedded competitors. I'm looking at things like SELinux here. Few other solutions (except e.g. Macaroons) are actually capable of making correct authorization decisions in scenarios involving 3+ principals: the competition is broken, and vicariously, so are most authorization systems which try to solve 3+ principal authorization problem correctly. You may as well be arguing that memory safe / garbage collected languages lost to C circa 1995. C is broken and programs written in C will always be full of holes as compared to equivalent programs in memory safe languages just in the same way as authorization systems not built to handle 3+ principals will make wrong decisions. This is why it's 2015 and we're still dealing with CSRF. If you implement SELinux at your job like I do, and have some informed criticism about how Capsicum is unneeded because SELinux is great, I'd love to hear it! But I'm guessing that isn't the case... I am also guessing it's an area the OP is not particularly informed about.
- pron 11y ago
  > you missed my original point I think you have simply misunderstood what the author is actually saying. He is not saying what you think he is, and I don't think you disagree with him at all. > The author thinks we're doing okay at security Where does he say that? He says, "security still isn’t a first class concern for most programmers", and puts it in the "No" column. > capabilities are still a promising solution. The author doesn't dispute that. In fact, he says nothing about the promise certain technologies hold. In fact, he says: "I’m much more optimistic about research areas that haven’t yielded much real-world impact (yet), like capability based computing and fancy type systems. It seems basically impossible to predict what areas will become valuable over the next thirty years." The article, however, is not concerned with possible solutions, even those that show great promise. It is only and solely concerned with solutions that have been conclusively shown to work well in the field by having a wide applicability and usage in numerous production projects. As capabilities -- so he says and you don't seem to dispute -- aren't there yet (he emphasizes the "yet"), they belong in the "no" column. That they show great promise -- or even maybe contain the only solution to problems we haven't been able to tackle -- bears absolutely no relevance to the issue of whether they "have worked" or not. It is a statement of fact that they haven't yet, and you don't seem to dispute that. Similarly, putting something in the "no" column doesn't mean that something has lost. The author makes that abundantly clear. A no may well turn out to be a yes in time. A no simply means "not yet" (while "maybe" means that it may in fact be "working" now, we just don't have enough information to conclusively say). The article therefore voices no criticism on the validity of certain technologies at all. That, too, the author makes abundantly clear. It is nothing more than a list of those technologies that to this day have (or haven't yet) been conclusively proven to provide significant benefits and wide applicability in the field. Those that only show promise belong in the "no" category. It is an inventory, not a critique. You have no argument (so it seems) either with me or the author. In fact, I have no knowledge on this subject at all: I have no idea what capabilities are, I have never heard of Capsicum (or SELinux for that matter) and have never even worked on security related issue. it was just clear to me that you are responding to criticism that is simply not there, and responding with great force by dismissing the author (who is very well versed in technology), which is rarely a good idea, especially if you don't carefully read what he has to say.

andrewflnr 11y ago

Yeah, all that stuff is why I'm enamored with them :). I didn't know about CapTP, though. I'll have to look at that more closely.