[cap-talk] Confused Deputies and Rights Amplification

[Jonathan S. Shapiro]

[Change of subject line, because I don't have time to track the rest of
the thread.]

On Mon, 2008-02-04 at 08:13 -0800, Mark Miller wrote:
> On Feb 3, 2008 10:39 PM, Jed Donnelley <capability at webstart.com> wrote:
> > [...] it seems
> > to me that what people refer to as "rights amplification"
> > poses a risk of producing confused deputies,
> 
> Yes. This still needs to be explored in depth.

Norm will jump in if I get this wrong, but I think it is safe to say
that both of us feel that no rights amplification operation should exist
in a properly designed capability system.

Or at least, that was his initial position, which gave both of us some
discomfort about the can-opener operation in KeyKOS/EROS.

Subsequently, I have modified my stance on this. It seems fairly clear
that:

  Any rights amplification operation that could, in principle, have
  been accomplished in the absence of the amplification operation
  (perhaps with a much higher storage or computational cost). Is
  not, strictly speaking, a rights amplification operation at all,
  and MAY be acceptable if it is implemented with sufficient care.

The "can opener" operation is a case in point. Given sufficient storage,
it is possible to implement this operation without kernel assistance.
What the canopener operation does is (a) eliminate the need for the
storage, and (b) reduce the operation from O(log n) to O(1).

I continue to believe that "there should be no fundamentally amplifying
operations" is a very good guideline.

I guess I would add one other qualifier. There are certain patterns,
such as seal/unseal, that CAN be implemented without an amplify
operation, but can only be implemented sensibly if 'eq' is available,
and can only be implemented efficiently if something like "keybits" is
available.  The decision to admit EQ into a design is a fairly
fundamental decision. One view of the debate is that EQ, by virtue of
violating identity encapsulation, is itself a rights amplifying
operation.

What seems clear is that canopener is okay if you are prepared to admit
either EQ or EGAL. If you aren't, then I think matters require further
thought, but I should think that this type of operation is probably
okay.

Oh. The essence of the user-mode implementation of canopener is that the
fabricator of processes with a particular brand can maintain a private
copy of all of the capabilities that it fabricates. Cracking open an
Endpoint for this purpose (equivalently: a red segment) is borderline,
but can be viewed as providing only a trivial extension of the notion of
EQ.


shap