How do you see this as different or the same as the facilities that the Phoenix
service, in River, already provides?
Gregg
On 6/6/2011 6:39 PM, Peter wrote:
There are trade off's using an additional jvm for isolation: the additonal
overhead and memory footprint.
One option might be; use the subprocess jvm for unicast discovery, one jvm for
each registrar, the subprocess jvm will also be used for running all service
proxy's from that lookup service. If there's an issue, the subprocess jvm can
be destroyed.
This makes the registrar partly responsible for the subprocess jvm, if the
lookup service contains a rouge service, then that lookup service suffers. A
method of communicating errors back to the registrar prior to exit might also
be useful, perhaps output from stderr.
The client would communicate with the subprocess jvm using reflective proxy's
and object streams over stdin stdout and stderr
The subprocess jvm would have very restricted permissions initially, a limited
classpath using classloaders for isolation between proxys, dynamic permissions
and possibly also revocable permissions, if required.
In effect downloaded code runs in separate jvm's, providing very good isolation.
This might form the basis of secure internet services.
Note, the idea of using a subprocess jvm was first suggested to me by Tim
Blackmann to prevent unmarshalling attacks, this was a solution Sun's dev team
were considering.
Cheers,
Peter.
----- Original message -----
Most on the list would be aware of the stillborn Isolates API, which
showed much promise fixing many of the issues the Java platform has in
supporting secure distributed code. EG:
1. Class Visibility
2. Subprocess Isolation.
3. Unmarshalling attacks.
Released with Java 5 (which is now our minimum supported platform),
ProcessBuilder and Process, can be used to create a separate process for
downloaded code.
We can modify MarhalledInstance to include an authentication reflective
proxy from the originating server which created it (eg: the
MarshalledInstance contains a smart proxy), but this limits interaction
to services and clients that know each other. Not much good if you've
got a mobile device and the lookup service you've just discovered is
unknown. People might want to remain anonymous for services where no
private information or currency changes hands, similarly to how the
internet currently operates. You execute downloaded code, when running
web scripts for example.
Java Thread isolation isn't safe enough, you might remember I
experimented with it recently, we could prevent creation of new threads,
catch a thread stack overflow, but we can't kill the misbehaving thread
and client code on the classpath is still visible to untrusted code,
making it possible for references to security sensitive objects from
client and platform code to escape into insecure code.
I've also worked on Security Delegates, which prevent references to
security sensitive objects from escaping allowing revocation of
permissions. I've created a custom security manager for this which also
caches the results of security checks for much faster repeated checks.
Using these features, we could completely isolate a smart proxy and
control the permissions and visibility of classes it has.
The isolation environment would contain a minimal subset of River,
Service API and any downloaded codebases the smart proxy needs.
A reflective proxy and invocation handler would be used to interact with
the isolated smart proxy. No code would be downloaded by the client
jvm, this would also make it possible for the smart proxy jvm to utilise
a different version of River, that is serialization compatible, via a
codebase download.
I suppose we could even make it possible to isolate the ServiceUI too.
One other problem is the migration from Unicast Discovery V1 to V2, the
serialized form of Discovery V1 is MarshalledObject, V2 uses
MarshalledInstance. Unicast Discovery V1 has no security considerations
whatsoever, this exposes the client to a number of different attacks.
We could use isolation to make Discovery V1 safer for existing code that
uses Discovery V1 only. To take advantage of Discovery V2 requires a
recompile I believe.
Thoughts?
Peter.
