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

Jonathan S. Shapiro shap at eros-os.com
Mon Jul 30 11:50:36 EDT 2007


On Sun, 2007-07-29 at 21:30 -0400, David Chizmadia (JHU) wrote:
>     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.

Umm. I gave at least one example of a statically configured system that
does not dynamically resort to a user interface, so I'm not sure why you
say this.

>     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).

I strongly disagree.

This issue is precisely why I placed the decision procedure within the
powerbox. *One* possible decision procedure is to consult the user. It
is not the only possible decision procedure. I gave an example of a
powerbox -- a firewall -- whose decision procedure is internally
executed.

> Upon receipt of a request for a guarded
> capability, the powerbox initiates a structured protocol with a
> well-known external entity ( the controller)...

This description of the pattern indicates that the controller *must* be
external to the powerbox. I was very careful in my definition to *avoid*
this requirement. Other than that, I like your pattern description.

>     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.

Indeed. It is noteworthy that neither standard reflects this. The notion
of "security through controlled polyinstantiation" is completely absent
in those standards. More broadly, the standards do not reflect any
comprehension of the difference between a protected module (in their
language: subsystem) interface boundary and a protected object
[instance] boundary. This is a significant weakness in the architectural
assumptions that underpin both standards.

shap



More information about the cap-talk mailing list