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

Jed Donnelley capability at webstart.com
Mon Jul 30 11:26:52 EDT 2007


Thanks for the note noteMarkS,

I hope you also feel it's worthwhile discussing the concept
and 'honing' definition(s).

One aspect below that seems to me most distinctive about
your original definition that I hadn't though of before
is the emphasis on "diverse elements of authority" and
the "complex trust boundary".

In the way I've been considering power boxes (somewhat
simplified I think?) the "diverse elements of authority"
are simply whatever authority (set of reachable permissions)
the power box is able to marshal.  The "complex trust boundary"
is simply the boundary of a message request.  I.e. the
'supplicant' (I sort of like that term, not supplied by
me of course) asks for a permission and the power box
object (program) chooses what to return or not depending
on it's policy and input.

If you feel that the "diverse elements of authority" and
the complex trust boundary" add flexibility to the
definition, could you perhaps give us some examples where
the simple set of permissions available to the power box
object (process) and a simple supplicant don't suffice for
the full glory of the power box concept?

At 07:55 AM 7/30/2007, Stiegler, Marc D wrote:
>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
> >
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk




More information about the cap-talk mailing list