N.B. No released versions of River / Jini's Jeri are secure now. Ignoring that for a moment, how you establish the connection is important also.
Regards, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz> Sent: 13/02/2017 11:34:45 pm To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy 1. The connection can be done using normal (secure) Jeri. We do not have to verify the installer object since its classes were loaded locally and (by definition) are trusted. 2. The attacker cannot instantiate any non-local class. That is the whole point. Since the "installer" classes must be local, then we can trust the installer to honor any invocation constraints we place on it. So any code downloads are secure - in the sense that the client can require authentication/integrity/confidentiality etc. Note that (if necessary) we can apply the same logic recursively - we can provide an "installer of an installer" and still be sure any code download is going to honor the security constraints we require. Thanks, Michal Peter wrote: So this object that you have with a locally installed class is tasked with authenticating the remote service, provisioning and resolving a bundle, deserializing the smart proxy and registering it with the OSGi service registrar in a readResolve or readObject method? How do you propose the connection from the client to the service established in order to enable this to occur? How do you prevent an attacker from choosing a different class to deserialize? Regards, Peter. Sent from my Samsung device Include original message ---- Original message ---- From: Michał Kłeczek <mic...@kleczek.org> Sent: 13/02/2017 10:07:28 pm To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy Comments inline. Peter wrote: Mic, I'm attempting to get my head around your proposal: In the case of JERI, the InvocationHandler is part of the smart proxy's serialized state. A number of smart proxy classes will need to be unmarshalled before the UnmarshallingInvocationHandler is deserialized. The smart proxy contains a reference to a dynamic proxy (which sun called the bootstrap proxy) and the dynamic proxy contains a reference to your UnmarshallingInvocationHandler. This means the smart proxy must be unmarshalled first. How do you get access to UnmarshallingInvocationHandler without unmarshalling the smart proxy first? No no - I am saying about wrapping the smart proxy inside another object. It can be either a dynamic proxy, or simply an object that implements "readResolve" returning the unmarshalled smart proxy. More comments inline below. On 13/02/2017 6:11 PM, Michał Kłeczek wrote: We are talking about the same thing. We are turning circles, Peter - all of this has been already discussed. 1. Yes - you need to resolve bundles in advance (in OSGi it is not possible to do otherwise anyway) Agree. 2. You cannot decide upon the bundle chosen by the container to load the proxy class (the container does the resolution) Disagree, nothing in the client depends on the proxy bundle, there's no reason to provision a different version 3. The runtime graph of object places additional constraints on the bundle resolution process (to what is specified in bundles' manifests). Since you do not have any way to pass these additional constraints to the container - the case is lost. Disagree. The proxy bundle contains a manifest with requirements The stream has no knowledge of versioning, nor does it need to, there are no additional constraints. If the service proxy dependencies cannot be resolved, or it doesn't unmarshall, then it will not be registered with the OSGi registry in the client, client code will not discover it and the client will have no knowledge of it's existance except for some logging. This is totally backwards. That way no client is able to find any service because there is a chicken and egg problem - we do not know the proxy interfaces until the proxy's bundle is resolved. Understand that when you place a bundle identifier in the stream - it is equivalent to specifying a Require-Bundle constraint - nothing more nothing less. Additionally - to explain what I've said before about wrong level of abstraction: Your general idea is very similar to mine: have a special object (let's call it installer) that will install software prior to proxy unmarshalling. 1. For some reason unclear to me you want to constrain the way how this "installer object" is passed only via the route of ServiceRegistrar (as attributes) Disagree, I'm not proposing the service have any control over installation at the client, other than the manifest in the proxy bundle, nor am I proposing using service attributes, or the use of any existing ServiceRegistar methods (see SafeServiceRegistrar link posted earlier). If you think about it from the higher architectural view - there is no difference. It does not really matter what steps are made - important thing is that: a) you have a special object used to download code - this object is supposed to be of a class installed locally in advance b) the above object is used to create a ClassLoader that you will use it load the actual deserialized object's class It does not matter where the first object is taken from - be it "SafeServiceRegistrar", the stream itself, a JavaSpace or the Moon. Thanks, Michal
