[cap-talk] EQ and the object-cap model, MyCap?

[Valerio Bellizzomi]

On 27/12/2006, at 11.42, Jonathan S. Shapiro wrote:

>On Wed, 2006-12-27 at 14:02 +0000, David Hopwood wrote:
>> Jonathan S. Shapiro wrote:
>> > First, if the server S is subverted then (a) all objects implemented
by
>> > S have already been subverted
>> 
>> That's not necessarily true. In a system with per-object isolation,
>there is
>> an isolation barrier between any two instances of S. By assumption, the
>buffer
>> overflow can be exploited for some S objects and not for others. There
>are two
>> reasons why this might be the case:
>> 
>> 1) the buffer overflow is state-dependent;
>> 2) only some S objects are accessible to the attacker.
>
>David: Go read my note again. You are postulating two servers S, S'. I
>discussed this case lower down in my mail. In the case above, I stated
>clearly that there were multiple objects implemented by a *single*
>server S, and I think that what I said above is correct.
>
>Because you misread which case I was talking about, neither of your
>scenarios (1,2) is possible here.
>
>In the case of two server instances S, S', the first reason you give
>must be restated:
>
>  1) the buffer overflow is state-dependent, **and the ability of the
>     attacker to induce the vulnerable state in one server instance S
>     does not imply the ability to straightforwardly induce a comparably
>     vulnerable state in a second server instance S'.
>
>I consider this vanishingly unlikely.
>
>In regard to your second reason, if S is accessible to the attacker but
>S' is not, then S' cannot be attacked and no concern about encapsulation
>arises. Recall that for S to de-encapsulate capabilities implemented by
>S', S must be handed a capability implemented by S'. In that case we
>have already stepped out of your case (2), because both S and S' are
>presumptively accessible (through transitivity) to the attacker.
>
>> I agree that reason 1) may be unlikely (although not impossible), but I
>don't
>> agree at all that reason 2) is unlikely.
>
>What is your reaction to my statement just above that this case is not
>relevant?
>
>> > and (b) a second server instance S' can be
>> > subverted using the same means that were used to subvert S -- the
cases
>> > in which this might not be true are so vanishingly rare that they do
>not
>> > provide a source of design rationale. In order for independent
>> > vulnerability to exist, we must postulate:
>> > 
>> >   (1) A server having multiple server instances S, S',
>> 
>> There must be some disconnect of assumptions here. In a typical
>language-based
>> cap system, there is always logically a separate server instance for
each
>> object.
>
>The context of my comments was "a type unsafe server implementing
>multiple objects".
>
>> 
>> >   such that
>> >   (2) the server relies on some interface I having two
>> >       **distinct implementors** T, T', such that
>> >   (3) T can be penetrated, T' cannot, and
>> >   (4) penetration of T is sufficient to compromise S
>> 
>> If we consider reason 2) above, then none of this is necessary. There
>merely
>> have to be some S objects that are accessible to the attacker, and some
>that
>> are not. Then if we only have per-server isolation (for example, if all
S
>> objects share a memory space), the attacker can subvert objects that it
>does
>> not have direct access to.
>
>Now that the disconnect has been identified, would you consider replying
>again to the original note?
>
>> 
>> [...]
>> > Second, concerning the encapsulation failure:
>> > 
>> > I initially shared the view of David Hopwood, as noted above. Norm
>Hardy
>> > convinced me that I was mistaken.
>> > 
>> > Let us imagine that the author of the code that is commonly executed
by
>> > S, S' wishes for S, S' to communicate. Let us further imagine a
>reliable
>> > IsTypeOf? operation, which we have already agreed is essential. Note
>> > that IsTypeOf? is sufficient to violate encapsulation [Note further:
I
>> > am shifting to IsInstance?, because we have agreed that the robust
>> > IsTypeOf? operation cannot be implemented by the object itself.
>> > 
>> >   S executes TypeRecognizer(S).IsInstance?(S') -> True
>> >   S executes S'.HiddenMethod(UnencapsulatedKeyTo(S))
>> >   S' executes TypeRecognizer(S').IsInstance?(UnencapsulatedKeyTo(S))
>> > 
>> > S and S' can now communicate arbitrarily.
>> >
>> > Given this, it does not appear possible to prevent two instance S, S'
>> > that obey the same code to violate mutual encapsulation, and we may
>> > conclude that the IdentifyGateKey() operation of KeyKOS/EROS does not
>> > weaken security at all.
>> 
>> The protocol described above does not have the same security properties
>as
>> IdentifyGateKey, since it requires S and S' to explicitly participate
in
>the
>> protocol. Since only types that actually require sibling communication
>would
>> do so (in particular, only those types would give out unencapsulated
>capabilities
>> to their objects), any loss of encapsulation would be restricted to
>those types.
>
>I am now completely confused. The IdentifyGateKey operation is generally
>closely held by the implementing server, so the IdentifyGateKey
>operation intrinsically requires S and S' to explicitly participate in
>the protocol.
>
>I'm not sure what you mean here by an unencapsulated capability, so I am
>unable to comment on the rest of your statement.
>
>> IdentifyGateKey, OTOH, can be used on objects of any type (given the
>type's
>> brand key, which I'm assuming is normally held by its server).
>
>The brand capability is NOT disclosed to the server. It is held by the
>process creator that created that server and wielded indirectly. The
>process creator is part of the universal system TCB. If that gets
>broken, you may as well have hacked the kernel.

Somewhere it is said that strong boundary around the TCB is critical, and
that
any code trusted by an element of the TCB must be part of the TCB too
(here I recall my own notion of "core" which includes TCB and system
services).
If a portion of the TCB is corrupted, we must consider that all of the TCB
can be corrupted.

>
>shap
>-- 
>Jonathan S. Shapiro, Ph.D.
>Managing Director
>The EROS Group, LLC
>+1 443 927 1719 x5100
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk