[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: instance and instantiator
From: |
Marcus Brinkmann |
Subject: |
Re: instance and instantiator |
Date: |
Thu, 13 Oct 2005 23:45:39 +0200 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) |
At Thu, 13 Oct 2005 17:23:35 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
>
> The "weak" part needs explanation.
>
> Suppose that you hold a read-only capability to a node that contains a
> read-write capability? You fetch the read-write capability and you have
> now broken confinement.
>
> The effect of the "weak" restriction is to downgrade each capability as
> it is fetched, ensuring that the fetched capability is both weak and
> read-only. This downgrade is conservative. Endpoint capabilities, for
> example, become Void capabilities.
I always wondered about something related to weak. What you say
applies, presumably, to all kernel objects, and to a certain set of
"standard objects".
But what if I introduce a new type of objects, where even a "read
only" capability supports "writish operations"? Can I then break out
of confinement with the support of the server providing that
capability?
I am not really sure if I am asking a security question. Well, I am,
but maybe there is some obvious answer to it, for example that the
constructor will only insert capabilities of the known, good types,
and that any unsafe capability comes from the instantiator. That
would do the trick I think, but note that I am only guessing.
The actual question I think I am asking is if the interpretation of
read/write/weak only applies to the standard objects, or if it can be
extended to new object types, and what happens if you have object
types that don't fit this pattern at all.
Thanks,
Marcus
- Re: The Perils of Pluggability (was: capability authentication), (continued)
- Re: The Perils of Pluggability (was: capability authentication), Bas Wijnen, 2005/10/10
- Re: The Perils of Pluggability (was: capability authentication), Jonathan S. Shapiro, 2005/10/10
- Re: The Perils of Pluggability (was: capability authentication), Bas Wijnen, 2005/10/11
- Re: The Perils of Pluggability (was: capability authentication), Jonathan S. Shapiro, 2005/10/11
- Re: The Perils of Pluggability (was: capability authentication), Bas Wijnen, 2005/10/11
- Re: The Perils of Pluggability (was: capability authentication), Jun Inoue, 2005/10/12
- Re: The Perils of Pluggability (was: capability authentication), Bas Wijnen, 2005/10/12
- Re: The Perils of Pluggability (was: capability authentication), Jonathan S. Shapiro, 2005/10/12
- instance and instantiator, Neal H. Walfield, 2005/10/13
- Re: instance and instantiator, Jonathan S. Shapiro, 2005/10/13
- Re: instance and instantiator,
Marcus Brinkmann <=
- Re: instance and instantiator, Jonathan S. Shapiro, 2005/10/13
Re: The Perils of Pluggability, Ludovic Courtès, 2005/10/10
Re: The Perils of Pluggability, Alfred M. Szmidt, 2005/10/10
Re: The Perils of Pluggability, Jonathan S. Shapiro, 2005/10/10
Re: The Perils of Pluggability, Matthieu Lemerre, 2005/10/10
Re: The Perils of Pluggability, Alfred M. Szmidt, 2005/10/11