river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Kleczek <mklec...@contour-technology.com>
Subject Re: Towards Internet Jini Services (trust)
Date Fri, 01 Oct 2010 17:38:51 GMT
When I think about it some more - the below idea is not enough and we need a 
more general solution.
How about class annotation not being a String but rather an object... I have 
to give it some more thought.

Michal

On Friday 01 of October 2010 15:00:49 Michal Kleczek wrote:
> Folks,
> I'm reading this thread with a lot of interest and wanted to throw my 2
> cents.
> 
> 1. I think we should stop talking about "services" and "service registrars"
> when talking about downloading code - RemoteEventListener can be a smart
> proxy too...
> 
> 2. Java permissioning model is enough to trust that code will not do
> anything bad like read my bank account credentials. Of course we cannot
> check that the code does not have any bugs - we cannot solve halting
> problem anyway...
> 
> 3. I agree with Tom that making sure the code comes from a known source is
> enough to make a decision whether to run this code or not. But Jini already
> checks that (well... almost)- the only hole is that the check is done
> _after_ deserialization - so it means the code was executed _before_ the
> check was done. My question actually is - why don't we check an object
> before it is deserialized?
> 
> My idea would be as follows:
> a) _Never_ download code when deserializing data (objects) comming from the
> network (IOW MarshalledInputStream should behave like ObjectInputStream -
> use TCCL to load classes)
> 
> b) when sending a proxy wrap it in a dynamic proxy with invocation handler
> that has two objects: a ProxyTrust and a marshalled real proxy
> 
> c) upon receiving of a (smart) proxy prepare it using a preparer that wraps
> original proxy with the one that makes sure TCCL is set apropriatelly for
> each method invocation - this is necessary so that deserialization of
> subsequent objects received by the proxy is successful (see point a).
> The preparer would check if it is preparing the proxy with
> TrustedInvocationHandler, then verifiy trust using std. Jini trust
> verification, then retrieve the real proxy, get it's ClassLoader and
> return a TCCL setting proxy wrapping it..
> 
> Some code:
> 
> //returned by remote service
> //cannot deserialize passed instance before actually making the check
> //it is not a problem for the client because it is obtained from a trusted
> //ProxyTrust implementation
> interface MarshalledInstanceVerifier {
>   boolean isTrustedMarshalledInstance(MarshalledInstance<?> instance);
> }
> 
> class TrustedInvocationHandler implements InvocationHandler {
>   private MarshalledInstance<?> realProxy;
>   private ProxyTrust proxyTrust;
> 
>   Object getRealProxy() {
>     return realProxy.get();
>   }
> 
>   ClassLoader getRealProxyClassLoader() {
>     return getRealProxy().getClassLoader();
>   }
> 
>   protected ProxyTrustIterator getProxyTrustIterator() {
>     return new SingletonProxyTrustIterator(proxyTrust);
>   }
> }
> 
> class TrustedInvocationHandlerVerifier implements TrustVerifier {
>   private MarshalledInstanceVerifier delegate;
>   public boolean isTrustedObject(Object o, TrustVerifier.Context ctx) {
>     //check that o is a proxy with TrustedInvocationHandler
>     //...
>     TrustedInvocationHandler handler = ...
>     return delegate.isTrustedMarshalledInstance(handler.realProxy);
>   }
> }
> 
> What do you think?
> 
> Michal
> 
> On Friday 01 of October 2010 14:05:51 Zoltan Juhasz wrote:
> > Tom and all,
> > 
> > > When was the last time you analysed the contents of your
> > > newly downloaded log4j.jar, just to make sure it didn't
> > > contain anything nasty?  In that example, you trusted the
> > > download site (apache.org), and you trusted the download
> > > mechanism (HTTP - now that was risky!), and then you  trusted
> > > the stuff you downloaded.
> > 
> > I think this is a key observation. The Jini mechanism for trust is based
> > on trusting the source and the download channel  but that does not imply
> > anything about the quality of the code you're about to execute. When you
> > download anything manually (in your browser), you have time to decide
> > whether or not you take the risk. Jini however is about programmatic
> > clients doing this automatically without human intervention. The speed
> > of execution is at a different scale. One would need semantic
> > correctness checks which is impossible to do right now. We had bumped
> > into this problem when we used Jini for distributed/parallel computation
> > and the only solution we could come up was to have accountability and a
> > mechanism for non-repudiation, ie you code can do stupid things but I'll
> > catch you and make you pay for it.
> > 
> > I don't know whether there is a universal solution to this, it is a very
> > complicated problem.
> > 
> > 
> > 
> > 
> > Zoltan

Mime
View raw message