black-box re-use? (was: Re: [E-Lang] MintMaker with ACLs)

Marc Stiegler marcs@skyhunter.com
Tue, 6 Feb 2001 17:25:51 -0700


David Wagner <daw@mozart.cs.berkeley.edu> wrote in message
news:95d14j$he$6@abraham.cs.berkeley.edu...
> Marc Stiegler wrote:
> >In fact, though there is considerable code required to completely wrap
> >AWT/Swing while granting users all the functionality of these packages in
a
> >capability-secure fashion, I now have an architecture and plan that does
> >this complete wrapping, in addition to a small proof-of-concept emaker
> >package that securely wraps the whole system (though it does not yet let
> >through all the functionality, i.e., the security is complete, but the
> >functionality is not yet).
> >
> >I believe that anyone who looks at AWT/Swing through a capability lens
will
> >conclude that this is a pretty impressive demonstration of the power of
> >capability architecture to refactor delegated powers without rewriting
> >existing code.
>
> Could you help me understand why this is attributed to use of
> capabilities?  From your description, it sounds like this might
> be explained as the power of interposition (and adding a level of
> indirection) -- but you have been diving in the guts of AWT/Swing,
> and I haven't, so I suspect I'm missing something.

Certainly, interposition and indirection are key elements of the capWT
system that I built for wrapping up the AWT/Swing functionality in a
capability disciplined way. I will outline some of the specific techniques I
used for one small but critical part of the process, and allow you to draw
your own conclusions as to how much the success depended on capabilities per
se.

The JFrame widget is the part of Swing used to draw window frames. It has
numerous flaws as a capability-disciplined object. Problems and solutions
include:

Problem: The setIconImage method allows the application (henceforth called
"caplet", since these are the apps confined by E) to engage in forgery, by
using the icon from the Quicken application, for example.

Solution: When a caplet is launched, an individual capWT instance is built
and handed to the caplet for user-interface. When constructing the capWT
instance, the launcher specifies an icon image. When the caplet requests a
JFrame, it gets a JFrame wrapper. The JFrame wrapper sets the icon image as
specified by the launcher, and suppresses the setIconImage method. This
actually follows the Pet Name pattern described in detail by markm at the
erights site, and is described in general in E in a Walnut.

Problem: The setTitle method also can be used for forgery, but since titles
are used for other things besides app names, a disciplined access to the
title should be enabled for the caplet.

Solution: The capWT instance also has a caplet-name specified by the
launcher. When a JFrame is created, the JFrame wrapper sets the title as
specified by the launcher. When the caplet calls setTitle on the wrapper,
the wrapper intercepts the call and builds a new title in which the
launcher-specified name is the prefix; in other words, the caplet has the
ability to append to the base title, but not to engage in successful forgery
of another app's name. This is also the Pet Name pattern, but with spice.

Problem: A pane is to be set aside at the bottom of the frame through which
capWT can communicate with the user, and effectively intermediate the
granting of powers on the user's behalf. This frame must be inaccessible to
the caplet, otherwise the caplet could manipulate the widgets there and
possibly trick capWT into granting new powers.

Solution: When a JFrame is created, the JFrame wrapper creates a pair of
panes, one above the other in the JFrame's ContentPane. The capability on
the bottom pane, which is the "powers bar", is handed back to the launcher.
When the caplet requests getContentPane, the JFrame wrapper intercepts the
request and returns the top pane rather than the raw ContentPane. Meanwhile,
the getParent method is suppressed for all widgets: the getParent method is
a convenience method in AWT/Swing, if you should have the authority to get a
parent, you have other ways of navigating to it available.

Problem: Since all the AWT/Swing widgets must be wrapped, the "add" method
in the JFrame (which allows widgets to be placed in the container) has a
problem: the JFrame will not be receiving actual widgets. Rather, it will be
receiving widget wrappers, which are not subclasses of Component and would
throw exceptions.

Solution: Using the Sealer/Unsealer capability pattern, all the widget
wrappers offer a public method to getSealedComponent. Both the sealer and
the unsealer are part of the capWT instance, created during its
construction. The JFrame wrapper, being inside the capWT context, can unseal
the component and forward it to the JFrame when it intercepts an "add"
message.

Problem: The bringToTop method of the JFrame would allow the caplet to
periodically bring its window to the top, becoming the keyboard focus,
stealing characters the user was typing into another unrelated window.

Solution: the zero-parameter bringToTop is suppressed. A new 1-parameter
bringToTop is enabled in the wrapper: the single parameter is a list of the
caplet's windows from which the caplet is authorized to "steal" activation.
If one of the windows in the list is on top, the wrapper fulfills the
request, and the JFrame is brought to the top.


One interesting feature of this wrapping process is that, by and large, the
way a caplet writer works with widgets is the same through capWT as it would
be working directly with Swing. There is very little learning curve
involved. The caplet author is barely aware that he is working in a
capability-confined space, he makes calls to objects just the same way he
normally would. The largest impact in this example--which is incidentally
one of the largest impacts in the whole system--is the requirement to send a
list of windows into the call to bringToTop. This is visible to the
programmer and is being done strictly for security purposes. Everything else
is just programming the way he would do it anyway.

The other interesting feature is, of course, that I am doing this all with n
ot a spec of access to the underlying toolkit. It is from things like what I
have outlined here that I hope we can identify an interesting statement to
make about the effectiveness of capability systems (or at least E as a
capability system) for extensibility.

--marcs