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

[David Chizmadia (JHU)]

Jed,

    Thank you for your thoughts. I think that you are correct that
the powerbox is a generally applicable pattern. I had added
"capability" to modify design pattern at the last moment, so it was
somewhat poorly thought out.

    I think that dropping "and exposure" from your definition is a
bad idea. It is frequently the case that many of the requests to a
powerbox result in the return of a permission with less scope than
the original permission (e.g., we often talk of return a read-only
permission to a file based on the original read-write permission).

    Even with the fact that the powerbox is a general concept that
can be effectively used in ACL systems (especially in the way James
Donald suggests - as a way of essentially transliterating an
underlying ACL model into a runtime capability model under the
direction of a human user), I think that it will end up being an
absolutely crucial pattern in capability systems.

    In all of my thought experiments about how to construct an
operationally useful capability system, I have always ended up using
a powerbox to implement, enforce, and monitor (audit) policy within
the running system. For instance, I think that the SELinux Type
Enforcement policy model could be implemented on a confined OCap
platform using the powerbox (as defined in this thread), facet, and
membrane patterns, and the Horton protocol.

-DMC

Jed Donnelley wrote:
> At 06:30 PM 7/29/2007, David Chizmadia (JHU) wrote:
>> ...
> 
> I've found the powerbox discussion interesting, not so much
> for clarifying the idea of a powerbox (which I think has been
> pretty clearly defined by interactions on the cap-talk list),
> but for putting words to the notion.
> 
> For my reading the discussion has improved the definition
> through the couple of iterations so far.  I consider this
> one the best so far:
> 
>>     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.
> 
> However, I don't think the powerbox notion needs to be restricted
> to capability systems.  I grant that dynamic control of permissions
> (capabilities) by parameter passing is much easier than what
> is typically available in systems based on programs running
> with 'user' identities and object access based on ACLs identifying
> users.  Still, I can easily imagine a power box in an ACL based
> system.  In fact, doesn't the (a?) Polaris powerbox qualify in
> this regard?  As I recall it must grant permissions to a
> 'null user' in accord with the wishes of it's interactive
> user (controller as above).
> 
> So, I'll try a restatement of the above in accord with my
> comments:
> 
> A 'powerbox' is a design pattern for controlling distribution
> of permissions.  The powerbox program runs in a domain
> (execution environment with defined permissions) with some
> permissions that it can grant on a selected or modified
> basis to a 'supplicant' (from a separate execution environment)
> that can make requests of it.
> 
> Often powerbox programs run under control of a human user
> (e.g. through a user interface such as a GUI) to grant
> selected or modified permissions to programs that request
> such permissions (e.g. read access to a file or write
> access to a DVD writer), but any form of control can fit
> the definition.
> 
> Just some thoughts.  I don't feel strongly about this
> definition.  It seems to me the basic notion is pretty
> clear.  Still, I do find it helpful to put words to the
> notion to try to clarify it a bit.
> 
> --Jed  http://www.webstart.com/jed-signature.html 
> 
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
> 
>