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
