Re: Opaque storage

[Pierre THIERRY]

Scribit Marcus Brinkmann dies 10/01/2007 hora 02:57:
> 1) In your proposal, it is only B that is unable to use "dangerous"
> capabilities.  But if B is not trusted, then it makes sense to extend
> this policy to all processes reached transitively by B, unless we have
> external reason to assume that they are trustworthy.

No need. Let the magic of POLA apply. (I'll become a mystic supporter of
POLA in a short time, believe me...)

> In other words, B can easily compromise your design by instantiating a
> helper process and off-loading any dangerous activities to that helper
> process.

I challenge you to sketch a precise scenario where it achieves that... B
has not the needed authority.

To instantiate a process, B needs authority, but it has none, as
certified by it's constructor. And even if it were given authority to
instanciate other confined processes, it could only give them capabilies
it holds. But it doesn't hold any dangerous capabilities, because the
guard holds them.

You see, the beauty in the reference monitor is that it forms a jail
without effort. That's the magic of POLA: you don't have to check for
something or prevent anything. You just don't let enter dangerous
authority in the jail, and no subject in the jail can ever become
dangerous...

> The automatic translation by G to _any_ external process will ensure
> that.

That doesn't make sense: how will S receive the usable capability, then?

> 6) On a more general note, I want to point out that the general
> objective of my proposal is by no means new. [...] It is a general
> design pattern, definitely useful and in fact very necessary under
> some circumstances (again, auth protocol).

Where is the auth protocol needed?

Curiously,
Pierre
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature