Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Michal Kleczek <michal.kleczek@xpro.biz>
Organization: XPro Sp. z o. o.
To: river-dev@incubator.apache.org
Subject: Re: Towards Internet Jini Services (trust)
Date: Fri, 1 Oct 2010 15:00:49 +0200
User-Agent: KMail/1.13.2 (Linux/2.6.31-22-generic; KDE/4.4.2; x86_64; ; )
References: <4C9DB5BF.8090307@zeus.net.au>
 <AANLkTimS6dg85wXqPW99qBrU23sK=Y5qK6X7c9YOsWD-@mail.gmail.com>
 <CA36A28E7BFA4F80916058A3436B14CA@irt.vein.hu>
In-Reply-To: <CA36A28E7BFA4F80916058A3436B14CA@irt.vein.hu>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201010011500.49853.michal.kleczek@xpro.biz>

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