[cap-talk] Capability-based Projects - theory vs. practice

[Norman Hardy]

On 2007 Aug 2, at 12:57 PM, Jonathan S. Shapiro wrote:

> On Thu, 2007-08-02 at 11:59 -0700, Jed Donnelley wrote:
>> Jonathan S. Shapiro wrote:
>>> Actually, I don't consider Mach a capability system either.
>>>
>>> One issue is that the unit named by descriptors in both systems  
>>> is the
>>> server, not the object implemented by the server.
>
>> Hmmm.  It's been a long time since I looked into this aspect of these
>> systems in detail, but as I recall this may (?) end up being more
>> a quantitative distinction than a qualitative distinction?
>>
>> It's certainly true that Mach (and I believe DEMOS at least
>> falls into the same category, perhaps Chorus?) referred to
>> their protected objects as "port"s.  This suggests more of
>> a "network address" sort of use...
>
> You are correct. A mach thread may have many receive ports,  
> enabling it
> to use ports to name objects. Further, it can aggregate these into  
> sets
> so that it can do "receive on any" operations.
>
> However, Mach is at best an impure capability system. There exist  
> system
> calls other than "invoke capability", and the Mach documentation is  
> very
> careful to characterize it as "capability-like" (their term).

Here is a note I wrote some time ago on Mach and Aegis vs. Keykos:
http://cap-lore.com/CapTheory/KK/Contrasts/cont.html

A major shortcoming of Mach in my opinion (described above) is that if
(1)  you and I are on the same capability platform
(2)  I find a bug in the file logic allowing me to run code with the  
authority of the file logic.

then I can the read and write your files.

In the same situation with Keykos the integrity of your application  
depends only
on the way you use the file system.
I can corrupt only my own files.

In short all files are served by the same object in Mach (and thus  
Mac OS X).
In Keykos each file gets its own isolated object and only the  
immutable code is shared.

Exploits such as hypothesized above generally involve sending invalid  
messages to the file server which fails to check for validity.