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 13:29:19 GMT

> ----- Original message -----
> > 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.
> > >

Just to clarify, we don't need invocation handlers on everything, only the
service interfaces (those that implement Remote), just don't grant
DownloadPermission to the same jvm the client runs in.  Rely on serialization
instead.  Each jvm gets its own independant copy of parameters and returned
 Objects.

If you trust a service and want to keep copies of Objects from the service proxy
that extend service api method return Objects, then grant DownloadPermission.
Then you get to have your cake and eat it too.  The returned object stays in the
client jvm in a separate classloader, the client only interacting via the parent
object from the service api.  The service proxy in the separate process can be
garbage collected, since its no longer needed.

This is not possible at present, instead the smart proxy classloader and classes
 sharing the jvm with the client are not garbage collected.

 Cheers,

 Peter.

> > > 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.
>


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