On Monday 04 of October 2010 15:39:44 Sim IJskes - QCG wrote: > On 10/04/2010 03:28 PM, Michal Kleczek wrote: > > The service can upload it's code to any code server available (it does > > not have to be trusted). It can upload it's proxy to any untrusted > > ServiceRegistrar or JavaSpace available. > > Yet still - the client can make sure it is talking to the right service > > via the right proxy. > > The only hole is that a DOS attack during proxy deserialization can be > > issued by a malicious service registrar. The question is - can this > > problem be solved? > > I'm not sure, thats the only attack vector. The problem is already > present in the lower layer: JERI. > > To me a service registrar is nothing more than a lookup table, > associating service attributes with service UUID, and service UUID with > ServerEndpoint+Object UUID. When you have selected the service, your > classloader still has to download the code, but thats the responsibility > of classloader and codeserver, who are verifying the trust relation.
It does not matter how the client got the proxy (be it from a ServiceRegistrar, an email message or a JavaSpace). You use a Security.verifyObjectTrust() to check if the proxy is the right one. This in turn establishes a secure channel with the service (which _must_ authenticate to the client in a secure setup) to retrieve a verifier. The problem is - you have to first deserialize the proxy. During deserialization or downloaded class initialization and then when retrieving ProxyTrustIterator the only thing that can happen ( if JVM security does not have holes ) is DoS since the code does not yet have any permissions. Michal
