river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Towards Internet Jini Services (trust)
Date Tue, 05 Oct 2010 14:36:47 GMT
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
>


Mime
View raw message