On 10/1/2010 12:38 PM, Michal Kleczek wrote:
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.
There are been some thought and discussion about doing this. It is possible,
but the problem becomes that if you send an object with the annotation, then how
does the receiver unmarshall that object? Is that object something that
everyone knows about ahead of time?
Gregg Wonderly
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
