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

[Marcus Brinkmann]

David-Sarah Hopwood wrote:
> 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.)

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.  This value judgement is not contained in the definition of an
object capability system as far as I know.  I am not saying that your position
is unreasonable, just that it includes more than "pure ocap".

>> 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.  You may want to check out side-channel attacks on
cryptographic keys using caching effects.  They are devastating.  Here are two
papers on the subject from 2005:

Cache Attacks and Countermeasures: the Case of AES
http://people.csail.mit.edu/tromer/papers/cache.pdf
Cach sharing for fun and profit
http://www.daemonology.net/papers/htt.pdf

To be clear: Access to memory load/store instructions is in this particular
case far more damaging (by several magnitudes) than global read access to my
passphrase-encrypted key file.

Thanks,
Marcus