river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Towards Internet Jini Services (trust)
Date Wed, 13 Oct 2010 00:04:27 GMT
Ok, I think that we've all got pieces of this puzzle and it's a doozy.

We can solve this, by our heads & ideas together.

I've got some thread isolation code that anticipates the StackOverflowError.

Michal's got the idea of using a reflective proxy in an annotation 
Object for verification authentication.

So how about this:

Alter or extend MarshalledOutputStream to append the verification 
reflective proxy after the String, in the writeAnnotation method.

Then we can use any existing URL scheme, remain compatible with earlier 
versions and verify and authenticate the other end and ensure privacy 
constraints have been met etc.

Then if the other end authenticates, we trust it.

This can be all isolated on a Unmarshalling Thread in a Single Thread 
ExecutorService, where any StackOverflowExceptions are handled and 
wrapped as IOExceptions for the client thread and no foreign code runs 
or can be downloaded, until we authenticate and grant it.



Michal Kleczek wrote:
> On Tuesday 12 of October 2010 15:39:52 Michal Kleczek wrote:
>> On Tuesday 12 of October 2010 15:07:07 Sim IJskes - QCG wrote:
>>> I dont like the idea, that we allow full deserialization before we have
>>> had a change to let the IntegrityVerifier have a look at it.
>> But suppressing recursive readAnnotation already does that!!!
>> Doesn't it?
> Even without this we do not run untrusted code.
> What can happen is attacker can send u a corrupted stream that contains of 
> Modules annotated with Modules - but no untrusted code will have a chance to 
> run.
> In the end you're going to get StackOverflowError and quit.
> Michal

View raw message