river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michał Kłeczek <michal.klec...@xpro.biz>
Subject Re: River-436 - need some explanation of preferred class provider
Date Wed, 05 Mar 2014 13:44:37 GMT
Greg,

I cannot agree more with the statement that mobile code is the cornerstone of 
River. I do not want to send just "data" (XML/JSON/whatever). I want to 
exchange _objects_ (data + code - well... in the end it is all data :-) ). And 
I want it to be _secure_ and ubiquitous.
IMHO we should just make it work - because it simply does not work at this 
moment - as shown in my example.

What I'm arguing is that it is not fixable with hierarchical class loading. The 
problem is that the client simply does not know what should be the "parent" 
when deserializing objects. Your River-336 patch is not going to change it 
(while still important since RMIClassLoader dependency is really a PITA).

I am not proposing any particular solution at this moment - BUT I would really 
like the community to have a second look at existing solutions before coming 
up with yet another one.

The requirements - as I see them right now would be:

1. Make it possible to exchange arbitrary object graphs composed of objects 
which classes are from _different_ codebases.
That would make it possible to create smart proxies wrapping other services' 
smart proxies (which in theory is possible today... but in practice is not)

2. Do not allow yet untrusted code to execute. Ever.
It basically means that from security perspective current algorithm:
- deserialize an object
- ask it for secure proxy
- ask the secure proxy for a verifier
- verify the original object
is just simply wrong :)
What's more - if we only allow trusted code to execute then the whole proxy 
verification problem becomes much simpler - all those complicated 
UntrustedObjectSecurityContext tricks are no longer necessary - it is enough 
to just ask an object to verify itself (placing apropriate invocation 
constraints on it first).

The River-436 patch is going to (mostly) solve 2. The only potential holes 
left are in unicast response parsing where ObjectInputStream is created to 
read MarshalledInstance from the network - opening possibility of DOS or other 
attacks exploiting local code vulnerabilities.
It is also going to open a possibility to solve 1 because it is going to make 
class loading algorithms extensible/dynamic.

The big question is whether it is possible to fix 1 without imposing any 
"container" or "class loading scheme" on the client/service implementor.

OTOH - while we do not provide any "container" today - we do provide a 
"platform". There is no way any client can work without having jsk-
platform.jar in its classpath and without specifying PreferredClassProvider as 
RMIClassProvider and configuring httpmd url handler.

Regards,

On Tuesday, March 04, 2014 08:03:13 PM Gregg Wonderly wrote:
> One of the greatest things about Java is serialization and mobile code!  One
> of the most limiting aspects of any language is Serialization!
> 
> If you have an interface or data class that two classes need to access,
> there is no choice but to have a common parent class loader.  Your client
> can institute such as class loading scheme completely independently of
> Jini’s use of some other class loading scheme, provided that you at least
> allow the “parent load this please” mechanism of hierarchical class loading
> to occur.
> 
> My changes to remove the explicit reliance/dependence on RMIClassLoader in
> River-336, and instead allow you to plug in how the “parent load this
> please” call out to work, is how you can solve this so that it actually
> works for your clients special needs.  The best thing is that this
> mechanism can be plugged into, at runtime, whereas RMIClassLoaderSPI is a
> onetime thing that requires access to the app class loader, which might not
> be possible in some clients.  All that is required is a security grant that
> allows a particular codebase to plugin a specific class name.
> 
> Gregg Wonderly
> 
> On Mar 4, 2014, at 7:39 PM, Gregg Wonderly <gergg@cox.net> wrote:
> >> On Mar 4, 2014, at 12:02 AM, Michał Kłeczek <michal.kleczek@xpro.biz>
> >> wrote:
> >> 
> >> The real problem is that Util interface is in two codebases. It should be
> >> in a single codebase shared between UtilProxy and WrapperProxy.
> >> But to make it possible we would need to have peer class loading like in
> >> ClassWorlds or OSGI.
> >> It is not solvable in a standard hierarchical class loading scheme.
> > 
> > This is one of the good examples of where hierarchical loading can present
> > challenges.
> > 
> > But the question really is, can an arbitrary client really expect for
> > arbitrary services to interact correctly?  If you want them to do this,
> > it has been shown over and over that global types are the best, least
> > troublesome choice.
> > 
> > If you want ubiquitous interactions why not use string based values such
> > as XML or better yet, JSON?
> > 
> > Then code and data is immune to class loading snafus and not bound to a
> > container or hosting "standard"!
> > 
> > Gregg
> > 
> >> Anyway... It is not really River-436 problem so my patch proposal is
> >> going
> >> to have the same issue since it is just a replacement for String
> >> annotations and not change in class loading scheme.
> >> 
> >> Thanks,
> >> Michal
> >> 
> >> 4 mar 2014 06:38 "Michał Kłeczek" <michal.kleczek@xpro.biz> napisał(a):
> >>> 1. The problem is there is no such thing as "the service interface". It
> >>> is
> >>> context dependent. What is "the service interface" for service browser?
> >>> 
> >>> 2. In this particular case Util interface is an implementation detail of
> >>> WrapperProxy. It is Wrapper interface the client is interested in. So I
> >>> would say it should be preferred in WrapperProxy codebase.
> >>> 
> >>> 3. Even if Util is not preferred in WrapperProxy codebase we still have
> >>> ClassCastException if the client does not have Util in its classpath.
> >>> Why
> >>> should it? it is interested in Wrapper not in Util. So either
> >>> a. We always get ClassCastException if Util is preferred in WrapperProxy
> >>> codebase, or
> >>> b. We get ClassCastException anyway if a client does not have Util in
> >>> its
> >>> classpath.
> >>> Let's say I want to register RemoteEventListener that wraps a Javaspace
> >>> proxy to write events in a space. Does that mean the service "event
> >>> source"
> >>> has to be aware of Javaspace interface??? That would be absurd...
> >>> 
> >>> It all does not have anything to do with codebase services.
> >>> 
> >>> Thanks,
> >>> Michal
> >>> 
> >>> 4 mar 2014 00:09 "Peter" <jini@zeus.net.au> napisał(a):
> >>>> The Util interface should not be preferred.  Implementations of Util
> >>>> can
> >>>> be preferred but not Util itself.
> >>>> 
> >>>> Services need a common api that all implementations and clients can
use
> >>>> to interract, even if this is a kind of codebase service.
> >>>> 
> >>>> Modifying an interface is generally considered bad practise but now
> >>>> Java
> >>>> 8 makes it possible to add default methods for added functionality,
> >>>> that
> >>>> line blurs somewhat.  What can you do if an earlier interface is loaded
> >>>> by
> >>>> a parent ClassLoader and you need a later version, make it preferred?
> >>>> 
> >>>> My thoughts are that interfaces should never be preferred and all
> >>>> classes
> >>>> defined in their methods shouldn't be preferred either.
> >>>> 
> >>>> It would be relatively easy to write a new implementation that ensures
> >>>> that interfaces are loaded into their own ProtectionDomain in a parent
> >>>> ClassLoader.  But that would be confusing as dynamic policy grants are
> >>>> made
> >>>> to ClassLoader's not ProtectionDomains.
> >>>> 
> >>>> But using ProtectionDomains in this manner, preserves security, ensures
> >>>> maximum visibility and avoids codebase annotation loss, if we ask the
> >>>> ProtectionDomain for the annotation, instead of the ClassLoader.  But
> >>>> this
> >>>> is not how we do things presently.
> >>>> 
> >>>> Cheers,
> >>>> 
> >>>> Peter.
> >>>> 
> >>>> ----- Original message -----
> >>>> 
> >>>>> But it will also be loaded by WrapperProxy ClassLoader, since it
is
> >>>>> preferred there. So it will end up with ClassCastException, right?
> >>>>> 
> >>>>> Regards,
> >>>>> Michal
> >>>>> 
> >>>>> If Util is installed locally, it will only be loaded by the
> >>>>> application
> >>>>> ClassLoader, since it isn't preferred.
> >>>>> 
> >>>>> Peter.
> >>>>> 
> >>>>> ----- Original message -----
> >>>>> 
> >>>>>> Folks,
> >>>>>> while woking on the River-436 patch proposal I've came across
the
> >>>>>> scenario that I am not sure how to handle:
> >>>>>> 
> >>>>>> Utility service:
> >>>>>> //inteface is NOT preferred
> >>>>>> interface Util {...}
> >>>>>> //class IS preferred
> >>>>>> class UtilProxy implements Util {}
> >>>>>> 
> >>>>>> Wrapper service:
> >>>>>> //NOT preferred
> >>>>>> interface Wrapper {}
> >>>>>> //preferred
> >>>>>> class WrapperProxy implements Serializable{
> >>>>>> //initialized with Util impl from a lookup service
> >>>>>> private Util util;
> >>>>>> }
> >>>>>> 
> >>>>>> Wrapper service codebase includes Util interface but it is
> >>>> 
> >>>> _preferred_.
> >>>> 
> >>>>>> Would deserialization of WrapperProxy end with ClassCastException?
> >>>>>> From what I understand UtilProxy is annotated with its codebase.
When
> >>>>>> deserializing UtilProxy a ClassLoader is going to be created
with
> >>>>>> parent set to TCCL. It means Util interface is going to be loaded
> >>>>>> twice by two ClassLoaders - one for WrapperProxy codebase and
another
> >>>>>> for UtilProxy codebase.
> >>>>>> 
> >>>>>> Am I correct?
> >>>>>> And if so: is it desired behavior?
> >>>>>> 
> >>>>>> Regards,
> >>>>>> 
> >>>>>> --
> >>>>>> Michał Kłeczek
> >>>>>> XPro Quality Matters
> >>>>>> http://www.xpro.biz

-- 
Michał Kłeczek
XPro Sp. z o. o.
ul. Borowskiego 2
03-475 Warszawa
Polska
-- 
Michał Kłeczek
XPro Sp. z o. o.
ul. Borowskiego 2
03-475 Warszawa
Polska
Mime
View raw message