[cap-talk] Another "core" principle, capability communication

[Valerio Bellizzomi]

On 29/12/2006, at 3.17, Jonathan S. Shapiro wrote:

>On Thu, 2006-12-28 at 17:34 -0800, Jed Donnelley wrote:
>> Restating the source of my confusion might help.
>> 
>> What I was thinking is that since the generic capability invocation
>> mechanism allows both data and capabilities to be sent and
>> to be received (in most [all?]) object-capability systems, that
>> seems to me to suggest that this statement:
>> 
>> "...subjects can transmit capabilities anywhere they can
>> transmit data, which is not the case in most capability
>> systems."
>> 
>> is true in most (all?) object-capability systems.
>
>Jed:
>
>Almost all capability systems actually do differentiate take/grant
>permissions from read/write permissions. While your statement is
>generally true about SEND operations (which is why unmediated entry
>capabilities need to be handled with care), you are neglecting the case
>of capability transmission via shared storage, which is restricted in
>the way that I stated in most real capability systems.
>
>
>For KeyKOS/EROS/Coyotos specifically, the weak access right is also
>relevant. A weak capability has the property that any capabilities
>returned from an invocation on a weak capability are subject to a
>downgrading transformation. The net effect of this transformation is
>that no capability conveying mutate authority can be obtained
>(transitively) by starting from a weak capability.
>
>While the weak right applies only to Node keys in KeyKOS, it is
>generalized to other kernel object capabilities in Coyotos.
>
>In fact, the definitional statement of behavior of any kernel capability
>in KeyKOS/EROS is:
>
>  "Invocation of a kernel capability proceeds as if an entry capability
>   to an implementing service were invoked, the response is computed by
>   unspecified means, and is returned to the invoker as if by invocation
>   of a resume capability."
>
>This implies that the weak right is conceptually a right on send
>capabilities and resume capabilities, even if it isn't currently
>implemented that way in KeyKOS/EROS/Coyotos. Pragmatically, the
>extension of the weak right to entry and resume capabilities is
>straightforward.
>
>> However, any specific service enabled by a capability may
>> not actually accept or return any capabilities.  For example,
>> a service like a file service may permit sending in (writing)
>> of data and/or receiving (reading) of data, but may not permit
>> any sending across of capabilities (grant) or receiving of
>> capabilities (take).
>
>I agree, but note that for purposes of information-flow based analysis
>we must assume that all non-TCB processes are maximally cooperative with
>attackers, and therefore do not restrict messages in this way.

That is why in my notion of core I include (trusted) system services. But
I can revise the definition in this way: "TCB includes kernel and trusted
system services", meaning by this that TCB == core.

>
>This illustrates a potentially significant advantage of language-based
>capability systems over network and OS-based capability systems. The
>OS-based analysis must treat the program as fully opaque, while
>language-based systems (which might include native code systems if we
>postulate proof carrying code) can often be subjected to less
>conservative analysis. For example, it is possible in many language
>systems to determine that a given service is "memoryless" (i.e. retains
>no state after return), and in some cases it may be possible to check
>that the property you give above is observed.
>
>> That suggests that while the generic capability invocation
>> path may permit capability communication, specific services
>> in general will not, so the statement:
>> 
>> "...subjects can transmit capabilities anywhere they can
>> transmit data, which is not the case in most capability
>> systems."
>> 
>> is false.
>
>The basis for this statement was the observation that nearly all
>capability systems of the time had permission bits for TAKE and GRANT
>that were distinct from the permission bits for READ and WRITE, so I'll
>stand by the statement as written.
>
>> Of course I did realize this and believe I understood
>> both Boebert's argument and that in the Myths paper.
>> What I really didn't understand was the basis for the
>> disagreement and whether it really rested in that sentence:
>
>Our assertion is derived from (1) non-explicit assumptions made in the
>paper that READ/TAKE and WRITE/GRANT were not differentiated. The paper
>implicitly relies on this failure of differentiation in its argument at
>several points, and (2) statements by Boebert that tend to confirm this
>interpretation of his argument.
>
>
>Deviating from the point you were making, I want to inject something
>here about the "weak" right that is relevant to the discussion of
>"necessary" access rights. In non-language systems, something like the
>weak permission is a precondition for efficient isolation, because the
>weak write is a requirement for mutually isolated read-only or
>copy-on-write sharing of deep structures. In language systems, it is
>possible to substitute a language-based analysis that a subsystem is
>"memoryless".
>
>
>> Considered in this light, one thing that seems clear about
>> the proposed approach to satisfying the *-property in the
>> Myths paper is that it cannot allow capabilities to flow
>> "freely" (that is in accord with the policies of any services
>> that may be ignorant of the MLS requirements) across security
>> levels.  This would seem a rather severe limitation on the
>> usefulness of any system.  The KeyKOS monitor approach for
>> watching communication between levels comes to mind.
>
>I think you are projecting your personal value judgment of "usefulness"
>onto a user (the MLS customer) who was optimizing for different
>criteria. Perhaps that system is not useful to *you* as a consequence of
>the limitations it imposes. It is useful to *them* precisely *because*
>of the limitations it imposes.
>
>Free flow of capabilities is not a universal good.
>
>> I suppose one can argue that the *-property and the "simple"
>> security property make any sharing across levels pretty much
>> broken in any case, so when satisfying these properties
>> within the context of an object-capability system is
>> shouldn't be surprising that any effective resource
>> sharing between levels becomes effectively impossible.
>
>... and explicitly undesirable in the context of those systems.
>
>> I really didn't understand was the basis for the
>> disagreement and whether it really rested in that sentence:
>> 
>> "...subjects can transmit capabilities anywhere they can
>> transmit data, which is not the case in most capability
>> systems."
>> 
>> with Boebert arguing that in all "traditional" object-
>> capability systems they can and the Myths paper arguing
>> that they can't.
>
>Boebert's statement about "traditional" capability systems suggest that
>he hadn't actually read the documentation for any of those capability
>systems. CAP certainly didn't satisfy his statement, nor did Hydra, nor
>did the Chicago Magic Number machine, which was the very first one.
>
>
>shap
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk