river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Anonymity, Security - ProcessBuilder and Process
Date Tue, 07 Jun 2011 20:52:11 GMT
How do you see this as different or the same as the facilities that the Phoenix 
service, in River, already provides?


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.

View raw message