[cap-talk] origin of the power box

Stiegler, Marc D marc.d.stiegler at hp.com
Tue Oct 10 10:35:58 CDT 2006


> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Sandro Magi
> Sent: Monday, October 09, 2006 6:29 PM
> To: General discussions concerning capability systems.
> Subject: Re: [cap-talk] origin of the power box
> Kenton Varda wrote:
> > On a tangent:  Are power boxes necessary?  It seems to me 
> that if the 
> > UI provides the ability to drag-and-drop capabilities, 
> there's no need 
> > for the power box pattern.  Programs can simply present 
> dialog boxes 
> > asking the user to drag such and such capability into them.
> The window system is the powerbox in drag-drop scenarios.
> Sandro

Well, by stretching the definition of "window system", I suppose one
could say this. Indeed, if we had a gui toolkit specifically designed
for a capability desktop, rather than a couple of existing gui toolkits
that have been hacked into capability-shaped discipline, the stretch is
shorter. Certainly, in a desktop, an application's powerbox has an
intimate relationship with the windowing system.

But there are powerbox actions that have little to do with the
conventional definition of a "windowing system", even for a
capability-based windowing system. Here are some observations, I leave
it to the reader to contemplate what objects should be called "part of
the windowing system".

A traditional windowing system has no need to read or write files. While
a windowing system is necessarily dangerous (as a whole, it can surely
engage in window forgery), I have been looking forward to the day when
we write a windowing system from scratch and find that, lo, we pass no
file authority into that huge, necessarily-ungainly mass of code for
clipping regions, creating textures, etc. 

This vision/definition of a windowing system flies in the face of saying
the powerbox is the windowing system. Since you cannot grant an
authority you do not have, for the windowing system to be able to grant
all possible authorities during drag/drop, it would have to wield all
possible authorities. So, if we say the powerbox is "part of the
windowing system", we would probably say it is "the part of the
windowing system that holds all user authority". Of course, even if we
do this, then switching from the cap-Gnome windowing system to the
cap-KDE windowing system requires replacing a crucial part of your TCB,
so I'm not so sure this is a good place for the conceptual break anyway.
On the other hand, if different windowing systems supply different ui
facilities, powerboxes may have to be customized for the windowing
system anyway.

Meanwhile, other behaviors are less window-like. Drag/drop works well
for granting an authority, but what about revoking that authority? The
current plan for a future CapDesk includes a button/dropdown on the
powerbar that enables revocation of the authorities already granted to
the application. Is authority revocation properly thought of as a
function of the windowing system? How about the "kill this application
dead button, I don't care what the application thinks of the plan"
button also planned for the powerbar? Normally we think of the windowing
system as the servant of the app, but with the
kill-with-extreme-prejudice button, we see that the app is the servant
of whoever owns and implements that button.

Regardless of whether you call it part of the windowing system or not,
you still want the chunks of code that control authorities for an
application to be collected together in a single place so we can
security review it, and also so that the authorities being granted can
be contemplated as a coherent collection. For example, I can imagine a
more sophisticated policy that says, "I am happy to allow this app to
connect to the internet up until the moment when I allow the app to read
one of my (confidential) files, at which point, shut down the internet
connection, and do not allow this instantiation of the application to
connect to the internet ever again thereafter." The parts of the system
in control of the app's internet access and its file access better be
very tightly coordinated to enable such policies in which, any one
authority may be ok, but certain combinations of authorities are not ok.

> It seems like with the power box approach, you would need 
> some sort of namespace for your capabilities in order to 
> allow programs to request them.  Then, you'd need (dun dun 
> duuuuun) access control lists to decide what capabilities in 
> this namespace the program is allowed to access.  I like the 
> drag-and-drop approach since it totally bypasses these needs 
> and is user-friendly to boot.

No namespace is needed. Consider the drag/drop of a file in the current
CapDesk. The user drags the file from the file manager and drops it on
the app's window. The file manager, not the windowing system, has the
file object authority which is being conveyed; the windowing system does
not have or need broad file authorities to simply carry, via the
drag/drop module, the one file authority from manager to app. Meanwhile,
the app is born without the ability to be a drop target, i.e., it does
not start out with the authority to listen for a drop. However, it does
start out with the authority to request, from the powerbox that created
the app, that the powerbox put a drop-target listener on a particular
panel of the app's window, and to notify a particular part of the app
with the drop. The CapDesk powerbox always performs this request (the
reason the drop-target listening is not ambient is that, the app may not
want a less-trusted part of itself to be able to independently listen,
like the DarpaBrowser which must worry about what its malicious renderer
would do if the user dropped a file on the renderer, thinking he was
dropping it on the DarpaBrowser). (btw, there are reasons, beyond scope
of this email, why this may get fancier in the future, such that not
even the file manager has file authority, but rather the powerbox for
the file manager and the powerbox for the app share a sealer/unsealer
pair so that neither the file manager nor the drag/drop component of the
windowing system ever actually gets the full file authority, the app
powerbox will unseal before notifying and conveying to the app).

There is a namespace that maps authorities to names which, while not
global, is pretty important and influential. That is the map of names
used by the app and the installer to communicate application endowment

When the user clicks on an uninstalled app and says, "install", the
installer lights up, and then launches the app under total confinement.
It then asks the app, "what authorities do you request as endowments?"
The app returns a pure data object that describes, in terms the
installer understands, what authorities it desires (the darpabrowser
requests the petname DarpaBrowser, and the authority to go anywhere on
the internet). The installer then uses this information about app
desires during its negotiation with the user to decide what endowments
the app should really get (not necessarily at all similar, but in the
typical nonhostile case probably identical).


More information about the cap-talk mailing list