[cap-talk] Concening entry "ambient authority" in Wikipedia

[David-Sarah Hopwood]

Marcus Brinkmann wrote:
> David-Sarah Hopwood wrote:
>> Marcus Brinkmann wrote:
>>> So an object-capability system with capabilities that are widely held is not
>>> an object-capability system?
>>
>> The fact that world-readable files are readable to all processes, is built
>> into the "traditional Unix" access control model (without chroot etc.)
>> It is *impossible* in that model to create a confined process -- one that
>> does not have access to world-readable files, for instance. This indeed
>> precludes analysing the system as an object-capability system. In an
>> obj-cap system, even if a given authority was *widely* held, it would
>> always be possible to create a new subject that didn't have it.
>>
>> Unix with chroot, OTOH, can be analysed as an obj-cap system, although not
>> a very convenient or usable one. (In most obj-cap systems, creating a new
>> confined process does not require administrative privileges.)
> 
> I just want to point that this involves a value judgement on your side, namely
> that file system accesses are somehow more significant than other types of
> accesses.

I should have said, "although not a very convenient, usable, or secure one".
The fact that chroot only restricts file accesses would indeed be a glaring
security hole. My point was just that such a system does not immediately
fail to be an obj-cap system in the same way that "traditional Unix" does.
If you try to analyse it as one, then the deficiencies of chroot as an
restricted execution environment become obvious. Those deficiencies might
not hold for other such environments that could be supported on Unix,
though (as Plash demonstrates).

>>> A close analysis will reveal that the situation is not so simple.  For
>>> example, the wikipedia page "Object-capability_model" cites Java global
>>> variables as a different way to access resources.  But in a capability system
>>> memory load/store instructions are *modeled* as messages to memory pages that
>>> are part of the processes page table, where the relevant capabilities are
>>> named implicitely through the architectures process model.  And in fact, the
>>> hardware's page table is just an optimized implementation of those
>>> capabilities (the seL4 specification makes this correlation very explicit, to
>>> the point where there is a 1:1 correspondence between software capabilities to
>>> memory pages and entries in the hardware page table).
>>
>> I don't see the relevance. Capability operating systems typically allow
>> universal access to load/store instructions, but they don't provide
>> universal access to any particular address. Access to the load/store
>> instructions doesn't by itself grant significant authority.
> 
> Again, a value judgement.

No, just a mistake. You are quite correct, access to load/store instructions
*can* sometimes lead to a devastating leakage of authority via side
channels.

It is important to distinguish, however, between an system that was intended
to be an obj-cap system but is subject to a side channel attack, and a
system that was never intended to be an obj-cap system in the first place.
Traditional Unix is in the latter category.

The distiction is important because the side-channel attack in the obj-cap
system is potentially fixable, *or* is grounds for considering the system to
be broken relative to its security goals.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com