[cap-talk] What sustained interest in capabilities

[David-Sarah Hopwood]

Mitsu Hadeishi wrote:
> On Dec 27, 2008, at 7:35 PM, David-Sarah Hopwood wrote:
>> That's true to a certain extent. The main deficiency of this  
>> approach is that you end up with a system in which it may be 
>> possible to bypass the capability layer by taking advantage of flaws
>> in other layers. There are also impedence mismatches between the
>> layers that use different access control approaches. For these
>> reasons, I consider it only to be a short-term solution.
> 
> Of course, these are concerns, but as Voltaire said, "Le mieux est  
> l'ennemi du bien" (the perfect is the enemy of the good). The emphasis
> I've seen on top-to-bottom capability systems I believe has impeded
> the spread of capability security ideas in practice, and the
> net result is capability security remains a relatively little-known  
> and little-practiced architectural approach, when in fact, in my view,  
> it can and should be practiced right now, in production systems, as  
> Monty and I and the rest of us have done at our startup, as Google has  
> with the Caja project, and as I've done in another project I can't  
> discuss yet.

There is no conflict between implementing capability security one
layer at a time, and aiming for a top-to-bottom capability system in
the medium to long term.

> The "impedance mismatch" is also far less of a problem than it may  
> seem, it turns out, for reasons I won't elaborate on in detail here,  
> but in brief it's because once you wrap an external ACL-based service  
> in a capability (which can have arbitrarily complex code controlling  
> access), the laws of capability authority transfer then take over.   
> You really don't have to think in terms of ACLs at all, or the fact  
> that the service itself is unaware of the capability wrapper, from the  
> POV of the layer it is pure capabilities.

I disagree. Complexity is the enemy of security, and it's not possible
to make a system simpler by adding layers. Since an ACL layer is
typically already too complicated, it is only by removing such layers
that we can obtain a high degree of confidence in the security of the
whole system.

>>> I think this strategy ought to be applied far more frequently; [...]
>>
>> I agree with that, but possibly for a different reason: replacing  
>> layers individually is probably the only practical way to get to a
>> top-to-bottom capability system in the longer term.
> 
> I'm simply going to have to disagree here, quite strongly.  A well- 
> implemented capability security layer can be a huge boon for its own  
> reasons.  I agree that in the long run, a top-to-bottom capability  
> world may well be desirable, but I suppose I quite disagree that this  
> is the main reason to build capability layers.  Capability security  
> layers have their own powerful semantics which are immensely useful on  
> their own terms, and at the same time would serve to propagate the  
> concepts to the larger engineering world.  I was asked once when I  
> presented some of my ideas to one senior engineer, "If capability  
> security is so great, why hasn't it been more widely adopted by now?"

Because adoption of technologies (especially in the security field,
which is quite disfunctional in this respect) does not generally proceed
according to technical merit. Luck, and marketing, play huge roles,
that have been systematically underestimated by capability advocates.
There haven't been enough *fully* implemented capability systems
for one to get lucky. A partially implemented system stands no chance.

-- 
David-Sarah Hopwood ⚥