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.
