There's a new constraint AtomicInputValidation that jeri uses to prevent standard serialization being used.
Reggie has been granted DownloadPermission and DeserializationPermission but only for its own codebase. Reggie has also been granted necessary permissions to communicate with its service. No perms have been granted allowing Reggie to do anything else Reggie gives the client a dynamic proxy token (via SafeServiceRegistrar's lookup method). If your class is a client class you can give it the power to open network connections and do as you wish, but it's not a good idea to grant that power to Reggie. But it's also worth remembering it's risky to deserialize into privileged context and you're going to have to do that in this case. SafeServiceRegistrar will still allow you to use your wrapper class, it just adds an additional step of allowing you to authenticate that service before you deserialize your service wrapper, making it a little safer. You can grant permissions to services only to the codebase certificate signers if you want. Using the url in the permission grant just restricts it more, but it's not mandatory. Regards, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Michał Kłeczek <mic...@kleczek.org> Sent: 14/02/2017 07:39:52 pm To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy Comments inline. Peter wrote: > Some of your assumptions around forbidding code downloading are incorrect, >which means the other assumptions that rely upon it are also wrong. Which assumptions? I know about DownloadPermissions. And while using RequireDlPermProvider closes the security vulnerability, the problem with DownloadPermissions is that they are not flexible enough. They preclude scenarios like downloading code from BitTorrent or any other "locationless" source or any source for which the client does not have a URL handler installed. Scalability has to be understood in a broader sense. Not only in terms of runtime performance but also in terms of flexibility and openness of the system for extension. Contrary to RequireDlPermProvider the use of SmartProxyWrapper is both secure and flexible. > > 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. I have an impression that you are only moving the problem around. Is use of AtomicSerial mandatory? If not then it does not increase security in any way. And secondly: Based on what information are DownloadPermissions and DeserializationPermissions granted? Only URL of the jar file? See above for why it does not scale. Any other information would require changing the format of codebase annotations (like somehow encoding electronic signature in it). > > Downloading smart proxy's directly from each service, instead of Reggie >significantly reduces the network burden on the lookup service. This is exactly what my SmartProxyWrapper is doing. The real proxy can even be downloaded from a third party service (neither the lookup service nor the service itself). And the bootstrap proxy can be downloaded from whatever place the client wants to treat as the lookup service - it might be as well serialized base64 encoded TXT record in DNS. The beauty of it is that it is orthogonal to the lookup service interface - the lookup service now is just another service on the network - not being special in any way. Thanks, Michal
