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

[Stiegler, Marc D]

Being the guy who coined the term (much disliked when first introduced,
BTW), I can definitively state that the original definition (which is
always vulnerable to being forgotten in favor of more popular
definitions later) is found in E in a Walnut, the Patterns section,
http://www.skyhunter.com/marcs/ewalnut.html#SEC45

---- powerbox excerpt --- 

"The powerbox pattern collects diverse elements of authority management
into a single object. That object, the powerbox, then becomes the
arbiter of authority transfers across a complex trust boundary. One of
the powerbox's most distinctive features is that it may be used for
dynamic negotiations for authority during operation. The less trusted
subsystem may, during execution, request new authorities. The powerbox
owner may, in response to the request, depending on other context that
it alone may have, decide to confer that authority, deny the authority,
or even grant the request authority after revoking other authorities
previously granted.

The powerbox is particularly useful in situations where the object in
the less trusted realm does not always get the same authorities, and
when those authorities may change during operation. If the authority
grant is static, a simple emaker-style authorization step suffices, and
a powerbox is not necessary. If the situation is more complex, however,
collecting all the authority management into a single place can make it
much easier to review and maintain the extremely security-sensitive
authority management code.

Key aspects of the powerbox pattern include: .... "

--------

It would be possible to interpret this to conclude that the powerbox
always has a user interface component, since it speaks of "the powerbox
owner" as a source of granting decisions. However, inspection of the
more detailed discussion indicates pretty clearly this is not required:
in the example, the powerbox is completely automated, implementing an
algorithm in which the grant of authority B to the client object
automatically revokes authority A, demonstrating the dynamic nature of
the powerbox behavior without needing a user interface.

For those who like history, the term "powerbox" was first used in a
published document in the DarpaBrowser Report, it was coined during the
development of CapDesk -- an application in which the powerbox did
indeed have a user interface.

--marcs
 

> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of David 
> Chizmadia (JHU)
> Sent: Saturday, July 28, 2007 2:21 PM
> To: General discussions concerning capability systems.
> Subject: [cap-talk] What *is* a powerbox?
> 
> Hello all,
> 
> James A. Donald makes the following statement in one of his emails:
> > A powerbox is a user interface for designating entities and 
> granting 
> > permissions to access them.
> 
>     Aside from the fact that this assumes that designation 
> and access permission are separated, which implies that the 
> underlying system is *not* a capability system, the statement 
> limits the powerbox concept only to user interfaces. This 
> runs counter to my own definition and I would like to find 
> out if I missed something, somewhere.
> 
>     Since the term - and I believe, the concept - evolved 
> within the cap-talk community, I think that the cap-talk list 
> is a good place to come up with a normative definition for "powerbox".
> 
>     My understanding of the powerbox concept is that it is a 
> design pattern for allowing capabilities to be aggregated and 
> then sensibly released - either "as is" or with some form of 
> authority reduction.
> It finds its greatest immediate value as a design abstraction 
> for user interfaces, but is not - in principle - limited to 
> user interfaces.
> 
>     As an example design that uses a non-UI powerbox, 
> consider the following notional design for an RBAC system ...
> 
>     Each user and role entity is represented by a powerbox, 
> which holds all of that entity's capabilities. When a user is 
> authorized to assume a specific role, an administrator uses 
> the Admin interface (which in this case *is* a UI powerbox) 
> to delegate a capability to the role powerbox (using 
> something like Horton if accountability to the level of 
> individual users is needed). The role capability allows the 
> User - or software acting on behalf of the user - to traverse 
> a name space containing meta-data about each of the 
> capabilities that have been assigned to the role. When the 
> user (software) has a need for a specific capability, it is 
> able to treat the role name space as an extension of its own 
> name space. The major difference is that to use a role 
> capability, the user must explicitly request that the 
> capability be transfered to its own name space. The role 
> powerbox, according to a defined (possibly role-specific) 
> policy, will then either transfer or delegate either a full 
> or reduced authority instance of the capability to the user 
> software for operational use.
> 
>     I look forward to the opinions of others...
> 
> -DMC
> 
> PS: If we have already thrashed through this question and I managed
>     to miss it, please just point me at the thread(s) and I'll hang
>     my head and slink away, embarassed :-D.   -DMC
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>