Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <530E9A89.3040603@zeus.net.au>
Date: Thu, 27 Feb 2014 11:53:13 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
 rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 1.0
To: dev@river.apache.org
Subject: Re: [jira] [Commented] (RIVER-435) Proposed Standard for
 Single-Archive
 Service Deployment Packaging
References: <JIRA.12695948.1392814956957@arcas>
	<JIRA.12695948.1392814956957.83141.1393011680601@arcas>
	<1393023189.3899.5.camel@Nokia-N900>
	<B486F194-12A7-403D-90CE-6FE30CEAE212@gmail.com>
	<4C968F1D-7363-4337-B15C-3C237C5EC95A@gmail.com>
	<1393319080.10590.14.camel@Nokia-N900>	<530CC96D.3060502@xpro.biz>
	<CAJuA6A5_DnnYdubHM7yfY+4xMshW3cDBj31kZs55hLaipjcJfw@mail.gmail.com>
	<530CD482.9030807@xpro.biz>
	<CAJuA6A4QnojLObR83Tf=Uth6FUDe_4bVFfSjKa-48kcsFPvUsg@mail.gmail.com>
	<530CF874.8000701@xpro.biz>	<1393414225.12572.5.camel@Nokia-N900>
 <CAL2DxM7fLy941E6ZRd1EB5tAFm1qa5Lmfz56a025_m4_bL2=hQ@mail.gmail.com>
In-Reply-To: 
 <CAL2DxM7fLy941E6ZRd1EB5tAFm1qa5Lmfz56a025_m4_bL2=hQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

It was River-362.

You're assuming the Java sandbox is secure, history tells us otherwise.  
Your Module provider is quite interesting however and it could still 
serve a purpose for River, but it's outside the scope of River-362.

The proposed solution is to restrict deserialization to a list of 
classes that form a trusted computing base (only code audited as secure 
would be included), this then allows two things:

    * Ability of clients to limit deserialization to a trusted computing
      base while authentication and proxy verification is performed. (In
      java anything that implements Serializable can be serialized, so
      this is a small trusted subset of what is currently Serializable).
    * Additional benefit of allowing untrusted parties to interact
      securely using no code downloads, (java.lang.reflect.Proxy) based
      services, with a limited trusted computing base.

So it limits plain old Serialization as well, not just codebase downloads.

This solution would also work with your module provider.

Can I suggest creating a new Jira for your module provider, with an 
explanation of its capabilities and benefits?

Hope this helps explain it.

Cheers,

Peter.


On 26/02/2014 10:09 PM, Michał Kłeczek wrote:
> Peter,
>
> I think you dont remember the idea. It's been a long time.
> It DOES prevent untrusted code from executing because a codebase annotation
> is verified BEFORE it has a chance to load code.
>
> Regards,
> Michal
> 26 lut 2014 12:31 "Peter"<jini@zeus.net.au>  napisał(a):
>
>> ----- Original message -----
>>>> This. I like this. How would this work, would it be an Entry, an
>>>> attribute of the service (perhaps similar to the ServiceUI factory?).
>>> My PoC is attached to one of the issues in Jira (I'll try to find it
>>> tomorrow once I have some more time). It was discussed some time ago on
>>> this list mainly with Peter.
>> In our previous discussion, the aim was to determine a way to ensure that
>> no untrusted objects could be deserialised and thus prevent DOS attacks.
>>
>> Because ProxyTrustVerifier checks are performed after deserialisation,
>> this wasn't a good solution for that specific problem.  That doesn't mean
>> to say it wouldn't be useful for other purposes.
>>
>> The solution to avoid downloading untrusted objects, is to prevent
>> deserialisation of untrusted classes, by checking the serialization byte
>> stream and limiting deserialisation to a specific list of local classes
>> until after trust can be established.
>>
>> I think this combined with Dennis' method of provisioning codebases and
>> secure endpoints would be a very difficult to crack security layer.
>>
>> That doesn't mean that object based annotations cannot be used, making the
>> annotation field a String doesn't mean you can't deserialise any Object, it
>> just means that after an object other than String is deserialised, a
>> ClassCastException will be thrown, by that time an attacker may have
>> already created a ClassLoader, if deserialisation is performed in
>> privileged context.
>>
>> Once we depreciate RMIClassLoader and replace it with RiverClassLoading,
>> then we could allow annotations to be objects.  After all, codebase
>> annotations are also part of the serialised stream, so we can secure them
>> by limiting them to a known trusted subset of classes as stated above.
>>
>> Regards,
>>
>> Peter.
>>
>>
>>> Basically the idea is to change codebase annotation from
>>> java.lang.String which needs to be interpreted by the client to an
>>> object implementing an interface.
>>> This object can be verified in exactly the same way as normal proxies
>>> are verified ( by a TrustVerifier - in particular the ProxyTrustVerifier
>>> ). All that happens during deserialization.
>>> It does not have anything to do with Entries since it is implemented at
>>> the layer below that - hence is available for _all_ downoladed code (for
>>> RemoteEventListeners as well :-) )
>>>
>>> Regards,
>>> Michal
>>>
>>> --
>>> Michał Kłeczek
>>> XPro Quality Matters
>>> http://www.xpro.biz
>>>
>>