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
