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 process.
Hope that helps to clarify my thoughts.
Cheers,
Peter.
