In jgdms I've enabled support for https unicast lookup in LookupLocator this establishes a connection to a Registrar only, not any service. This functionality doesn't exist in River.
How do you propose establishing a connection using one of these endpoints? 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: 14/02/2017 12:00:02 am To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy KerberosEnpoint? HttpsEndpoint? Thanks, Michal Peter wrote: > How do you establish the secure jeri connection? > > 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<michal@kleczekorg> > 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 > > > > >
