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

[Marcus Brinkmann]

Mark Miller wrote:
> On Tue, Jun 9, 2009 at 4:25 AM, Marcus
> Brinkmann<marcus.brinkmann at ruhr-uni-bochum.de> wrote:
>> So an object-capability system with capabilities that are widely held is not
>> an object-capability system?
> 
> If authority bearing capabilities happen to be widely held, you may
> still have an object-capability system.
> 
> If authority bearing capabilities are necessarily widely held, i.e.,
> if A loading and instantiating code B cannot deny such capabilities to
> B, then you don't have an object-capability system.

I have a bit of a problem to decide that Unix is not an ocap system simply
because there was a conscious design choice to have undeniable capablities
within the model, while in real ocap systems the only undeniable capabilities
are only found outside the model by definition.  Formally, you are right that
using such definitions there is a difference.  But models fail dramatically to
capture real world systems, and that may provide you with a false sense of
security.  At the very least it does not allow you to transfer the reasoning
over the model to actual implementations of it.  In Unix at least people are
aware of the compromises they make with regards to those undeniably
capabilities that are made explicit (well, to some extent).  An attacker
doesn't care about models, but will attack implementations of it.

Furthermore, undeniable capabilities are an integral part of the constructor
design in EROS.  The constructor provides the starting process B with an
undeniable bag of capabilities.  There is a mechanism to decide if this set of
undeniable capabilities are safe, but the policy is hard coded in the
constructor (and partly in the system) design.  It's not mandatory to use the
constructor, and if you create your own subprocesses then of course you can
deny any capabilities, but use of the constructor is strongly encouraged in
EROS.  This situation is not very different from modern (if not traditional)
Unix, where the default process spawning method adds undeniable capabilities,
but numerous ways to build non-standard encapsulated processes exist.

Thanks,
Marcus