[cap-talk] What *is* a powerbox?
capability at webstart.com
Mon Jul 30 11:56:07 EDT 2007
At 04:41 AM 7/30/2007, David Chizmadia (JHU) wrote:
> 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).
The returning of a permission with less scope is what I was trying
to express when I included, "...grant on a selected or modified
basis...". It was the 'modified' that I intended to mean the return
of a permission with less scope - though I suppose some may suggest
that even the return of more scope would be possible with some sort
rights amplification. In any case I intended to include the
potential to modify returned permissions with that clause.
What is it about "and exposure" that to you suggests more clearly
the return of a permission with less scope? Those two words don't
convey that notion to me - so perhaps you are getting at something
Heh - is it time for a Wikipedia "power box" page? Right now there
would be a rather minimal name conflict:
Perhaps MarcS would like to propose a definition for such
> 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.
Certainly capability systems provide the underlying mechanisms
for dynamically communicating permissions (as 'capabilities' of
course) that makes the concept of a 'power box' seemingly most
directly applicable. Though I didn't use the term 'power box'
that was later coined by Marc Siegler (see:
) back in 'the day' (1970s, 1980s), we were considering basically
this same issue of how to dynamically grant new permissions
(which I generically referred to as 'capabilities' independent
of their implementation) in my Managing Domains paper where I
discussed 'Human Expression of Resource Access Control":
At the time we spent considerable time on both the initialization
aspect of running programs (which we referred to as 'utilities'
at the time vs. I think what people most often refer to as
'application's today) and the problem of dynamically conveying
permissions (capabilities) to running programs. At that time
we didn't have anything like open file windows that fit so
nicely into such a mechanism - namely with the same user
interface but with sadly inadequate functionality in
ambient authority systems. In ambient authority systems
with 'user' based access control such a window just ends up
saying, "Please name for me an object from all those that
I have access to as I exercise your ambient authority".
In a more POLA system it can say, "Please name for me an
object that you are willing to grant to me (add to
my limited permissions) so that I can accomplish the
work you've asked of me.
Seems like a clearly useful enhancement with little or no impact
on the user interface. I think that was a great contribution
from the work of MarcS and others on CapDesk.
> 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.
Whew. That seems to me a pretty big stretch (possibly because of
my relative ignorance of SELinux due to my negative interactions
with it), but I'm happy that you can even consider such an
More information about the cap-talk