river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Release 3.0, package rename and ServiceProxyAccessor
Date Wed, 06 Jan 2016 06:12:35 GMT

> On Jan 5, 2016, at 10:51 PM, Peter <jini@zeus.net.au> wrote:
>  <snip>
> ProxyPreparer in its current form is broken.  
> Proxy preparation assumed that both the java sandbox and serialization are secure, code
is downloaded, static class initialisers and readObject methods are executed on untrusted
foreign code, you're POWNED by the attacker, only then are invocation constraints applied,
then the proxy provides the bootstrap proxy, the service is authenticated, the bootstrap proxy
provides the TrustVerifier via a remote call and the TrustVerifier checks if the proxy can
be trusted, and finally method constraints are applied, oops, how can that possibly work?!

Perhaps I’m misunderstanding something - As I understand it, a proxy is deserialized into
a new, empty classloader - i.e. it begins with no permissions.  Permissions are only granted
by the ProxyPrepare.prepareProxy(…) method after trust verification is performed.  Am I
wrong about that?

> <snip>
> The broken concept of TrustVerifier is no longer required, the process is simplified
and much more secure.  
> All of the above becomes a ProxyVerifier and configuration concern; client code doesn't
need to be involved.

It already is a ProxyPreparer and configuration concern.  The TrustVerifiers are automatically
configured through manifest entries in the client library ‘jar’ file.  All the client
needs to do is instantiate a ProxyPreparer and call it on the proxy before using it.  In most
cases, BasicProxyPreparer is fine, since it uses the manifest-configured TrustVerifiers (which
would also be shipped in the client library).  Alternately, the service provider could provide
an alternate ProxyPreparer implementation.  What’s the problem, exactly, that this more
complex lookup procedure solves?

> This will require some backward compatible revisions to the lookup service, that we'll
need to discuss before implementing.
> All this should be up for constructive discussion, when the time comes, lets discuss
each argument concisely, park some for later discussion, so we can resolve any differences
we have and make progress.
> We also need to address httpmd insecurity, discuss whether to upgrade it, or deprecate
and replace with signed jar codebases.
> The network is changing, we can't cling to ipv4 and NAT firewalls to provide security.

I wish you’d stop making these unsupported straw-man assertions.  When has anyone ever said
anything about clinging to ipv4?  As far as NAT firewalls, the design is clear - Jini doesn’t
cross NAT firewalls.

> Activation removal has been voted on for 2.2, not 3.0, this is an understandable decision
from a maintence reduction persspective, considering that 2.2 is an LTS and completely separate
branch, that duplicates work.

Personally, I voted to remove it entirely - we just decided to remove it in the next iteration
of the 3.0 branch.

> It makes much less sense in 3.0, I've already performed the maintenance required on Phoenix,
I'm reluctant to throw that away just yet, perhaps it still makes sense to remove support
for jrmp activation, which will simplify phoenix and make it portable to other jvm's, but
why not retain jeri activation, it's portable?  Sun jrmp activation was intended as a compatible
uprade away from rmid.
> Users may not have noticed the recent vote to remove activation from 2.2, some felt quite
strongly about this in the past:

That was discussed and voted on.  Do you have a problem accepting the community’s decision?

I’ll say it again, Peter - River on the Internet is not going to happen.  Stop trying to
make it happen.  Roy is right about this - HTTP is all the protocol you’ll ever need for
the Internet.  We’ve talked about this several times, and each time, the PMC has said “no”.
 Fork the project and find a new community if that’s what you’re determined to work on.

Greg Trasuk

View raw message