In that case, I'll leave it alone and continue the release process My thoughts on the future of Security, to help dispell misunderstandings and incorrect assumptions (think about this now, make any investigations you need to and lets discuss after 3.0):
River Security in its present form adds complexity, is broken and poorly maintained. We provide software with web capable jeri endpoints over https and tls, but don't provide adequate security for services or clients. The need for security was established and was the driver for the Davis project prior to Jini 2.0. This "bootstrap proxy" is part of the Jini api, it's an instance of ProxyTrust as documented in Smart Proxy Trust Verification. Current implementations of ProxyTrust, TrustVerifier and ServiceRegistrar place significant burdens and complexity on developers, but don't deliver on security as promised by our javadoc. Can we afford to ignore security? Why do we complicate our code with policies and ProxyTrust if it's insecure anyway? Aren't there legal ramifications? Even Reggie, although it doesn't execute client code, is vulnerable, because it doesn't validate input. Any attacker can create any Serializable object on the classpath by crafting the serialization stream, some will deserialize into priviliged context allowing the attacker to create a classloader. The only other way to avoid this vulnerability is use tls and validate all clients, x509 certs are an ongoing expense, could you imagine the consequences if you were required to provide a cert to use a web browser? But that only helps Reggie, client security is still broken, so its not an acceptable fix. ipv4 and nat have restricted Jini adoption to local networks, http/s jeri endpoints allowed clients to contact publicly visible services, but ipv6 changes the ballgame so we can communicate directly from public networks with services on local networks. Security is required for ipv6 networks Committers have the right to veto any security fixes, however it is a requirement of veto to provide an alternative proposal, I'm flexible and willing to consider any proposal that addresses the issues. 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?! Jini security is overly complex and broken, it may have been ok in 2004, when isolates were planned... The bit about trusting local code (the boostrap proxy, credit Sun, not me) is only correct if combined with input validation and constraints are a good idea, so how I propose to fix security: Make RequireDlPermProvider default to ensure DownloadPermission is enforced. Introduce a new invocation constraint to enforce Serialization input validation. Introduce a new ServiceRegistrar default method that returns only bootstrap proxy's, consider them a token that can be used by a clients ProxyPreparer (Configuration concern) to: * authenticate the service. * obtain Entries from, if required for local filtering or ServiceUI. * obtain the service proxy. The sequence looks like this: 1. Deserialize the bootstrap proxy, with input validation for serialization (already implemented) to prevent DOS or becoming POWNED 2. check invocation constraints and authenticate the service. 3. dynamically grant DownloadPermission. 4. Ask the bootstrap proxy for the service proxy using ServiceProxyAccessor. Ask for Entry's using a new interface called ServiceEntryAccessor, to perform local filtering prior to retrieving the proxy if required. This also enables delayed unmarshalling. 5. Apply method constraints.. 6. Dynamically grant any remaining permissions required (I already have an implementation of jar META-INF/permissions.perm as per OSGi syntax to allow services to declare required permissions). 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. 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. 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. 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: http://mail-archives.apache.org/mod_mbox/river-dev/201403.mbox/%3c4794484.jaC2QK7xTF@mkleczek-laptop%3e Why not investigate how to evolve phoenix into a service watchdog as suggested? It could run remotely, with assistance from a remote executor service, that allows service hosting. That way, one service dies, another node takes over and resumes the service. In any case bringing up removal of jrmp and activation is only a distraction. While MarshalledObject is being used, so is JRMP. We must change our api to remove it completely. Interface default methods can be part of a migration and deprecation strategy. Security today is even more relevant than it was in 2004, not less. Regards, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Greg Trasuk <tras...@stratuscom.com> Sent: 06/01/2016 02:02:50 am To: dev@river.apache.org Subject: Re: Release 3.0, package rename and ServiceProxyAccessor -1 A few reasons; - ProxyAccessor exists primarily to go along with the activation system, which is slated to be removed. - ServiceProxyAccessor goes with the ‘start’ package, that is an implementation detail that not all containers use - Whether a service is implemented by a reflective proxy or a smart proxy is none of the client’s business, and the client code shouldn’t be coupled to the implementation of the service. - Ideas that go “in a future version of River” ought to be fully fleshed out and discussed before we start implementing them. In particular, this “bootstrap proxy” idea - I don’t intend to delve into it now, but I can’t help but wonder whether it’s better implemented using the existing ProxyPreparer mechanism, or some decoupling between the service item and its claimed interfaces. Not to mention, the need for it hasn’t been established. In any case, we shouldn’t implement things until we’ve talked about them. We’ve agreed to be cautious about changing the public API. Cheers, Greg Trasuk > On Jan 5, 2016, at 1:41 AM, Peter Firmstone <peter.firmst...@zeus.net.au> >wrote: > > ServiceProxyAccesor is an interface in the start package, a similar interface >called ProxyAccessor exists in the net.jini.export package. > > The difference between these two interfaces is the former returns a smart >proxy, which may not be a Remote object, while the latter returns the Remote >proxy which is a reflective proxy or remote proxy stub. > > Often, the former contains the latter, where the former implements service >api, while the latter is used for remote communication with the service's >server. > > In a future version of River, ServiceProxyAccessor could be used by clients >to obtain the service proxy, from a bootstrap proxy, allowing authentication >to occur prior to codebase download and unmarshalling. Think security and >delayed unmarshalling. > > If this was to occur, we'd need to change the package for the >ServiceProxyAccessor interface, to net.jini.export. > > Seeing as we're about to change the package of ServiceProxyAccessor in the >3.0 release, it would have less impact on downstream code if this change was >only made once. > > If the security and performance improvements were not accepted, (I'm quite >confident that we will agree on a solution once the benefits can be >demonstrated) it still makes sense to move ServiceProxyAccessor to >net.jini.exporter due to their related use and functionality. > > Should I proceed with a vote to move ServiceProxyAccessor to net.jiniexporter >now, prior to release, or should I leave it until River 31? > > This wont cause a delay in the release process, but I'm happy to leave it if >anyone is concerned it will. > > Regards, > > Peter. > > Sent from my Samsung device. >
