river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy
Date Mon, 13 Feb 2017 14:11:10 GMT
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.kleczek@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.kleczek@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 
> 
> 
> 
> 
> 



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message