river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: IsolatedExecutor
Date Sun, 18 Sep 2011 11:21:47 GMT
In reality, the heart of the problem is there a single shared memory heap for applications
sharing a jvm and we can't rely solely on permissions.

The interesting thing about the IsolatedExecutor is it may prove useful for improving low
memory conditions in trusted code.

Summing up the problems for distributed computing using java:

Class versioning conflicts.
Memory handling.
Class visibility.
Codebase mixing.
Codebase annotation loss.

The plusses:

Dynamic classloading
runtime binding
downloadable codebases
type safety
automated memory allocation
garbage collection

> What I'm wondering, is whether you are trying to solve a problem that represents
> the real issue.  "freely" executing code, is problematic.  We know that "process
> based" isolation, as well as "filesystem permission based" isolation can create
> a reasonable sandbox for "physical" damage to the computing environment.  In the
> end, both of these types of isolation use a "check and protect" based mechanism
> through the APIs that are part of those domains.
> When we look at the "shared state" issue in Java, the complexity of "check and
> protect" goes up by orders of magnitude, because ALL loaded classes have to have
> APIs that take the right precautions.
> This is one of the reasons why I hate JVM permissions as a "protection"
> mechanism overall, because they are not part of the "machine", but part of
> "select code".  Granted, the ones that are "filesystem permission based" seem to
> do well, but I worry about System.load("arbitrary path") and other thing that
> user code can do once particular permissions are granted (such as AllPermission
> opening all the doors).

I think protection domain and permission based security is useful, but incomplete, Java needs
better memory isolation, to  simplify security for developers.

> In my work on Jini services and clients, I have not focused on controlling
> specifics of client activities with permissions.
> Peter's work here, is a very complex issue because of how many more doors there
> are that can swing open to various parts of the system running downloaded
> service API.
> If you want to do isolation through separate processes there is a hard problem.
>    For deserialized classes that are not proxies on the outside (smart proxies of
> some nature), it will be difficult to have the right "type" on a "proxy with
> invocation handler" solution to call across processes.  Direct Field access that
> is part of a public API will be difficult to support with an invocation handler
> as well.
> ServiceUI presents a whole load of issues about how does the UI component
> hierarchy work if running in another process.  If from the outside, there is a
> ServiceUI container that would use JComponentFactory to integrate the service's
> UI into a more complex display, getting that to work in a separate process would
> be problematic because you'd have to abstract Graphics activities, mouse events
> etc., through the mechanism too.

I think you'd need to be able to trust the service first before using the UI,  but then we
never ask the proxy to verify the UI either, the development of Service UI predates Jini security.

It should be possible to dynamically grant permission between processes.  ProtectionDomain
and ClassLoader are not serializable but the proxy is, making it possible to hand the proxy
back to the subprocess with a set of permissions to dynamically grant.  

> I'm kinda with Tom that there just seems to be so much complexity here that I'm
> not sure, yet how to attack this issue.  We'd be creating so much code that we
> really would of built a completely new platform it seems.  That might be what's
> needed.  The bigger picture is not really gelling into a tangible set of
> concrete characteristics and actionable work items.

Seems is the right word, looking into it further it appears quite feasible, with a lot less
code than one might think, all you need is an executor service that runs in another process,
accepts discovery tasks and returns a future that contains an object, and another method that
accepts an object and permissions to be granted after verification.  The object returned is
the registrar of course.  You've always got the option of limiting permissions granted and
not trusting it, what harm can it do if it's isolated?

You could do much more with it than just isolate proxy's, any task that is memory hungry could
be run in an isolated executor service.  

You could just about use the existing java interface, although you'd have to add throws IOException.

> If we thought about it from the perspective of the "app store" model as Tom
> mentioned, where we'd expect "no" inter-working of services' codebases and
> classpaths, then maybe completely separate processes with a "standard" serviceUI
> container would be a good solution.  It would then start to feel more like the
> "Applet" environment.  But we'd still have the "Windows can create confusing and
> abusive UI components" issue that the Applet model tries to handle through
> disallowing

To use a UI requires trust, although you could grant permission for it to use a jframe and
run the UI in a separate process, then kill it if it plays up.

You'd just put the code for invoking the UI against the proxy in a Callable task then execute
it in the executor service.  The UI would pop up on the screen in a Jwindow from a separate

Hope that helps to clarify my thoughts.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message