Re: Opaque storage

[Alan Grimes]

Repeat after me:

STORAGE IS IRRELEVANT TO OPERATING SYSTEM DESIGN.

That is, of course, an extremely radical statement. However, if you can
manage to see the truth in it, and can fully understand it's
implications, you will come to understand one of the root causes of why
Linux is so awful. =(


Marcus Brinkmann wrote:
> At Wed, 10 Jan 2007 04:03:23 +0100,
> Pierre THIERRY <address@hidden> wrote:
>> [1  <multipart/signed (7bit)>]
>> [1.1  <text/plain; us-ascii (quoted-printable)>]
>> 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...)
> 
> Well, I don't believe in magic.
>  
>>> 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.
> 
> Ah, sorry, I see where I got you wrong.  I missed this part in your mail:
> 
>   "Along with a (proxied) capability to S, and as part of the protocol to
>    use S, B receives a capability c0 to use opaque storage, destined to S,
>                                                             ^^^^^^^^^^^^^
>    and marked dangerous to the reference monitor. The guard will keep c0
>    and give to B a capability to itself c1 that is just a no-op (but it
>    could also be used to notify A of the hostile character of B...).
> 
>    When B invokes the s1 capability to use S and includes the c1
>    capability, G will substitute it with c0, thus giving S authority to use
>    opaque storage."
> 
> This "destined to S" in your proposal appears to be exactly the
> tagging that I proposed.  Don't you think so?
> 
>>> 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?

-- 
|/-\|/-\|