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
