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: [jira] Created: (RIVER-362) Denial of Service during unmarshalling of smart proxy's
Date Thu, 28 Oct 2010 08:36:38 GMT
Michal Kleczek wrote:
> On Tuesday 26 of October 2010 15:27:17 Peter Firmstone wrote:
>   
>> Hi Michal,
>>
>> Sorry for taking time to respond, I've been busy and am still digesting
>> the code.
>>
>> Michal Kleczek wrote:
>>     
>>> In my code there is a simple hack to force creating a different
>>> ClassLoader for each unique Module - before calling to a delegate
>>> RMIClassProviderSpi I set a TCCL to a new ClassLoader that is unique to
>>> the Module. (That is also the reason I had to provide a slightly
>>> modified version of BasicJeriTrustVerifier so that not the proxy
>>> ClassLoader but also its parent are verified) See AbstractRmiModule for
>>> details.
>>>
>>> Module uniqueness: two Modules are considered the same iff their equals
>>> returns true.
>>>
>>> In case of ProxyTrustModule (which is the most interesting) - two
>>> ProxyTrustModules are equal when their codebases are equal and their
>>> ProxyTrusts are equal. so for two different services - each providing its
>>> own ProxyTrust for Modules - we create two different ClassLoaders
>>> regardless of the codebases. (This is not based on Subject but on
>>> service proxy identity) Basing it on Subject would be a little tricky
>>> IMHO because actual service Principals are dependent on what the client
>>> requires.
>>>       
>> Ok I see your point, we should be using service proxy identity, not the
>> Subject.  A server might use a number of subjects. Since not all proxy's
>> are services, would it be better to use the BasicObjectEndpoint identity.
>>
>> ProxyTrust, doesn't by default implement equals or hashcode, if the
>> client is handed a reference to a remote object, that is a smart proxy,
>> from another client, it could end up with two separate instances if
>> ProxyTrust uses the default Object equals implementation.
>>
>> So thinking about it a little more, perhaps we could use the Uuid of the
>> BasicObjectEndpoint?
>>     
>
> Hmm... I've checked BasicInvoationHandler and it implements equals for its 
> proxies by (among other stuff) comparing object endpoints.
> So in basic scenario (when ProxyTrust is a simple Jeri proxy) all is fine.
> For smart proxies I would simply require "sensible" implementation of equals. 
>
> It is in the interest of a service to provide a client with the right Module 
> identity - otherwise the service just won't work properly (but it will not 
> affect client's security). Equals for me seems to be the easiest and general 
> enough. I wouldn't want to base it on some internal stuff since that would 
> preclude Modules that are not Jeri based etc...
>
> Michal
>
>   
Ok Interesting, anyone implementing a Service should be quite capable of 
implementing equals, we should then specify that equals and hashcode 
methods should be implemented for ProxyTrust.

For my benefit can you go over the process of how your new code works?  
I'm interested in the choices you've made & why.

I still would like to wrap the ClassLoader in a GuardObject, this way 
less trusted code (you don't want it to see the ClassLoader) cannot 
obtain a ClassLoader reference, but it can delegate the functionality by 
passing the GuardObject to more trusted code.

A little off topic, but based on what we can do if we solve the DOS 
problem. I was just thinking today that we could create an Internet 
Service Browser, that discovered any service available over the 
internet, utilising ServiceUI, with which users can interact.  Just like 
Web servers and Web browsers, a River Service browser, wouldn't need to 
implement service (unless it advertised trusted services perhaps), it 
could be a lightweight app for minimal download.  It would be the web 
browser for services.  This could be done using DNS-SD to discover 
Unicast addresses of Lookup services.  This would render the app store 
model obsolete, anyone could advertise their service applications with 
their own lookup service.  It would blur the lines between applications 
and internet web sites.  We would also need delayed unmarshalling of 
proxy's or partial unmarshalling (only deserialize Entry's) until the 
desired service is found.

I'm wondering how we could use PGP Certificates web of trust and utilise 
JAAS to associate with local Principals?  Would these local Principals 
have standard names, representing levels of trust?  For maximum trust 
you would expect the Service to authenticate with all these Principals.

How could we authenticate the Service with these principals?

If a friend trusts and uses a service, can we use and trust that service 
too? Might that trust be the number of Principals our friends 
authenticates the service with? Or would we use a lesser trust? Could 
this be a role of an extended lookup service, to find services that have 
some kind of trust relationship?  Or would it be some kind of trust service?

If we can spell out these trust levels, then the service implementer 
knows which Principals are needed to gain certain permissions.  These 
principal based permission grants could be configured by default in the 
client.

Services might also expect clients to authenticate with these services.  
Any ideas?

Thanks,

Peter.



Mime
View raw message