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 Mon, 11 Oct 2010 21:03:54 GMT
On 10/9/2010 4:10 AM, Sim IJskes - QCG wrote:
> We can have a URL handler for downloading code over any medium. We could enforce
> only downloading code over trusted endpoints.
> Once we have the jar in the localvm, we can verify the codesigning of the
> classes. The only thing we need to do is to enrich the information passed to
> verifyIntegrity() from codebase to code.
> [or we could just have a caching url handler, and retrieve the code again (but
> this time from the cache) in a IntegrityVerifier. This would change nothing in
> the current river code. Any worms in this can?]

To reiterate what I've been using for my desktop clients policy management...

I have two files full of lines of text.  One is a list of host names, the other 
is a list of URL suffixes.



I have a URL handler which is a caching handler so that jars can be loaded from 
disk.  It always does a HEAD and checks date and size to be the same.  If 
missing, or out of date, it is downloaded.

I use a Codesource grant on all host:url combinations of AllPermission.

One simple side effect of this handler, is that if I have a test machine that I 
am setting up that is not production, the users see it, but until they add the 
host to their hosts.txt, all code downloads fail with file create/write 
permission checks on the caching handler.  So, they can't access the test 
services by mistake.  They will see an exception message about the file access.

Clearly, a purposeful attack, can provide urls that don't go through my handler, 
and get to the deserialization attack already mentioned (I ranted about this for 
some time many years ago, trying to see if I could get Sun to own up to it, and 
fix it).  Requiring download permission can mediate some of this in the endpoint.

Gregg Wonderly

View raw message