[cap-talk] What *is* a powerbox?

[David Chizmadia (JHU)]

Shap,

    Thanks for responding.

    Let me first note that we seem to have similar intuitions, but
also both ended up at the same point - that the powerbox is really
only useful in a user interface context. I think I may have found a
way out of that trap.

    The difference in our expositions was that you specified the
powerbox as a process, while I specified it as a pattern.

You wrote:

> Jame's definition is too narrow. Let me attempt a better one, but let me
> first say: James's confusion is very natural. The powerbox idea evolved
> during the design of an interactive system. The first powerbox
> implementations did operate in roughly the way that James describes, but
> the powerbox construct isn't limited in the way that he suggests.
> 
> A powerbox is a process that holds, or can obtain, capabilities that are
> potentially sensitive (the "guarded capabilities"). One or more
> applications have access to the powerbox via capabilities, and are able
> to request [copies of] these guarded capabilities. The powerbox
> implements a decision procedure by which it will decide whether or not
> to transfer the requested capabilities to the application, and if so,
> whether it will grant them in full-strength or reduced form, and whether
> it will introduce a membrane protocol around the transferred
> capabilities.
> 
> The decision procedure implemented by the powerbox may be stateful (i.e.
> its behavior for current requests may depend on past requests), and it
> may incorporate interaction with the user. Neither of these is a
> *necessary* requirement. A conventional, rule-based firewall that allows
> or refuses connection based on a table of rules may be viewed as a kind
> of powerbox.
> 
> So: I think James has the basic spirit of the thing right in the
> interactive case, but the powerbox idea goes beyond what he says above.
> I may have created additional confusion by stating that a powerbox
> should be viewed as an extension of a shell. Most people think of a
> shell as interactive. When I say "shell", I simply mean some agent
> software that is fully trusted to faithfully enact the intentions of its
> directing principal.
>
> I think that the notion that a powerbox is ultimately controlled by a
> principal is an important part of the powerbox concept. If we allow the
> concept to extend to arbitrary membranes having statically defined
> policies, then we are merely describing the notion of a security
> enforcing subsystem in general, and we shouldn't coin a new term for
> that. The descriptive utility of the "powerbox" notion lies in the
> presence of user control -- or so it seems to me.

    First, I very much like your addition of the term "guarded
capability" to the definition. It actually makes it clear that the
difference between the powerbox and a membrane is that the membrane
directly protects a service, while the powerbox protects a reference
(capability) to the service.

    An obvious deficiency in both of our powerbox definitions
(though not in your later discussions) was placement of the decision
procedure about what the powerbox will do about a request for a
guarded capability within the powerbox. After thinking about things
for a while, I realized that a unique characteristic of the powerbox
- and the thing that keeps leading back to us seeing it as a UI
mechanism - is that the *decision* about whether and in what form to
release a guarded capability is actually made outside of the
powerbox (usually by a human in current uses of the term). The
powerbox is primarily responsible for implementing the decision that
is made outside of itself.

    So I would like to propose the following revised definition of a
powerbox...


    The powerbox is a capability design pattern for controlling the
distribution and exposure of sensitive capabilities. The powerbox
holds, or can obtain, capabilities that are potentially sensitive
(the "guarded capabilities"). An external entity (the supplicant)
that holds a capability to the powerbox can request [copies of]
these guarded capabilities. Upon receipt of a request for a guarded
capability, the powerbox initiates a structured protocol with a
well-known external entity ( the controller) that will make a
decision about which capability to release and whether to provide a
full or reduced authority copy of the capability. The powerbox is
then responsible for releasing a capability to the supplicant that
conforms to the decision of the controller.

    In addition to the above normative definition, it would probably
be worth noting that software implementing a powerbox is usually a
key component of the TCSEC TCB (trusted computing base) or CC TSF
(trusted security functions) that enforce domain separation between
the powerbox supplicants and the services referenced by the guarded
capabilities.


    Looking forward to more comments,

-DMC