Gregg Wonderly wrote:
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.
hosts.txt:
hosta.here.com
hostb.here.com
hosta.there.com
urls.txt:
8090/reggie-dl.jar
8090/mahalo-dl.jar
8080/utils.jar
8080/otherutils.jar
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.
In the new RevokeableDynamicPolicy, I've made it possible to perform
dynamic grant's to CodeSource, so you don't need to define Codesource
grant's in files anymore, they can be delayed until required, you no
longer need to know the CodeSource in advance.
Same goes for Certificate[] grants.
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.
It should be possible to create a Security Delegate SocketFactory that
produce download limiting Sockets (or upload limited). Your given a
download limit, once you exceed it, permission to obtain new Sockets is
revoked and all existing InputStreams are closed on the next
invocation. The Sockets could be leased as well, so they can be cleaned
up if the caller doesn't close them or renew it's lease, (it would need
the permission to renew it's lease).
In this case the permission would be
DelegatePermission(SocketPermission) and Li Gong's Object Method Guard
pattern would be used.
Cheers,
Peter
