[cap-talk] Concening entry "ambient authority" in Wikipedia
David-Sarah Hopwood
david-sarah at jacaranda.org
Tue Jun 9 13:45:05 EDT 2009
Marcus Brinkmann wrote:
> David-Sarah Hopwood wrote:
>> Marcus Brinkmann wrote:
>>> Mark Miller wrote:
>>>> I would define an ambient authority system as one in which "If a
>>>> requesting entity requests an action that it is permitted to perform,
>>>> then the action is allowed." By contrast to a designated authority
>>>> system, in which "If a requesting entity requests an action that is
>>>> permitted by the subset of its permissions that it explicitly brings
>>>> to bear on the action, then the action is allowed." This formulation
>>>> also has the right paradoxical sense -- one can see why it was so easy
>>>> to think that ambient authority was a sensible architecture.
>>> I think that what is missing from this picture is how finely permissions can
>>> be described in the given system. For example, I don't see any reason why a
>>> traditional Unix kernel can not be interpreted under an object-capability
>>> glasses, as the object-capability model does not require that separable
>>> interfaces are actually separated.
>>
>> A traditional Unix kernel grants significant authorities -- for example,
>> the ability to read world-readable files -- to all [*] processes, so it is
>> definitively not an object-capability system.
>
> 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.)
> That I can formulate the question this way already seems to preclude the
> answer in my favor.
Well, being wrong does preclude an answer in your favour ;-)
> 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.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
More information about the cap-talk
mailing list