Hi Gregg,
Are you happy to donate the code from your http://pastion.dev.java.net
project and upload it to JIRA?
JERI is quite pluggable, so I'm confident we can integrate it without
getting tied to particular platforms and your code donation would be
very appreciated!
It's both interesting and understandable that both yourself and Dennis
are wary of remote code security, so I'll concede defeat on this
occasion, I consider you both more experienced than I, that also means
that if either of you feel the inclination, I invite you to please
consider becoming Committers with Apache River.
However as a separate interest, I'm looking into what can be done about
dynamically downloaded code and trust.
Currently when you install Apache River locally, you go to the Apache
web site, download the release, it's signed using pgp and you can use
asynchronous public key cryptography to confirm the file checksum. I
suppose a good DNS spoofing attack could destroy trust, if you didn't
have a copy of my public key locally.
To me, cryptography is just as important to dynamically downloaded
code. Today md5 is considered weak, httpmd may no longer be considered
trustworthy and is in need of a suitable replacement.
I'm working on a Concurrent replacement for DyanamicPolicyProvider, we
have the ability to dynamically grant permissions to a particular
ClassLoader with a set of Principals, OR a set of principals, OR a
ClassLoader. This is based around proxy trust.
I'm currently working on a new mechanism for storing permission grants
and considerably expanding the flexibility of dynamic permission grants,
to more faithfully replicate those of policy file permission grants and
then some.
So I'm working on allowing dynamic grants (and revoke) by:
ProtectionDomain (only exists at runtime, multiple may exist per
ClassLoader)
CodeSource (again multiple may exist per ClassLoader, in addition it can
exist in multple ClassLoaders, many to many relationship)
Certificate[] - Certs used to sign code.
These are in addition to Principal[] and ClassLoader.
The underlying theory, is to allow permission by divide and conquer of
trust concerns.
What can we do with the additional flexibility?
Well, for one, we'll be able to grant permissions based on the
certificates of the developers we trust, this will allow for peer review
of several companies or individuals that cooperate based on some common
code, after it has undergone peer review, we might also want to combine
this requirement with a particular set of Principals, who are allowed to
execute that code. Then this code will be considered safe for dynamic
download, update (developer trust, integrity) and execution (developer
and user trust must be satisfied).
You might want to revoke permissions based on a vulnerability discovered
in a particular CodeSource, without revoking certificates, principals
etc. Or if a group of certificates have become compromised, revoke
permissions specific to those.
I'd like to set up a Codebase where users can contribute their Service
Interfaces, Apache River can distribute these on their behalf, after
peer review. I'd like to create a runtime ClassLoader for Service
Interfaces, high up in the ClassLoader hierarchy so proxy's and clients
can cooperate using them. By allowing ProtectionDomain based
Principal[] permission grants, we can load codebase-less dumb proxy's
with the Service Interface ClassLoader, this solves problems with
ClassLoader visibility for non hierarchical ClassLoader relationships in
some environments, such as OSGi, although developers might want more
specific control of ClassLoader visibility, so don't take this as final.
Another benefit of ProtectionDomain based grants, a Service's smart
proxy might utilise a trusted piece of code, it might provide access to
a protected system resource. This trusted piece of code can reside in
the same ClassLoader with the proxy, visible only to the proxy and
within it's own ProtectionDomain to perform some function on behalf of
the proxy, without allowing whatever the secure concern might be, to
escape via the proxy, or allowing the proxy itself to be privileged.
This trusted piece of code could be based on a Certificate chain and
Principal[] and have its permission revoked as soon as it is no longer
needed. Trust for that code might be negotiated between the two
cooperating parties, or it might be posted for public peer review and
signing.
Once we have this additional power and flexibility, then we can build
infrastructure on top.
I believe we can create a new web environment in which people, equipment
and computers can cooperate based on models of trust, encryption and
dynamic code, utilising Apache River's Jini Services implementation. Or
we can die trying.
Come all ye developers, join in the fun, lets work together and get our
River flowing.
Peter.
