river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Anonymity, Security - ProcessBuilder and Process
Date Mon, 06 Jun 2011 02:38:57 GMT
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.



View raw message