Some of your assumptions around forbidding code downloading are incorrect, which means the other assumptions that rely upon it are also wrong.
In existing River Jini applications, code download can be limited by using RequireDlPermProvider, it's not possible for a Serializable class to do so via deserialization api. We must dynamically grant specific download permission after authentication, but prior to loading the remote code, this limits scope. If we using AtomicSerial we also need to dynamically grant DeserializationPermission. Downloading smart proxy's directly from each service, instead of Reggie significantly reduces the network burden on the lookup service. Thus security scales much better than remaining vulnerable in this case. Regards, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Michał Kłeczek <mic...@kleczek.org> Sent: 14/02/2017 03:43:39 pm To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy Wouldn't it be easier if you simply forbid code downloading during unmarshalling as in SmartProxyWrapper I've shown in another message? Then u use the unmarshalled bootstrap object to securely download the real proxy using existing Jeri implementation. Then you do not need any advanced discovery packet inspections at all. What's more - you can apply the same technique to every service proxy - so your security does not depend on how secure the lookup service is. Relying on the lookup service for security does not scale. If you dream of internet scale Jini it has to work in a similar way to current web. I can contact my bank securely even though an attacker might have taken control over my home router (so both routing and naming service is not secure). That's because it is built on end-to-end principle: it has to be secure even if the intermediate services (whatever they are) are insecure. The lookup service is an analogue to DNS. It shouldn't be necessary to make it secure to make the whole system secure. Thanks, Michal Peter wrote: > The certs aren't encoded in the codebase annotation, but sent in packets as >strings and bytes that are used to reconstruct the certificates during >discovery. > > The certs are also included in the jar file. If Download permission hasn't >been granted, the classes can't be defined. DownloadPermission is incorrectly >named, it should be called DefineClassPermission. > > Regards, > > Peter. >
