167.

  

Client Requirements

The client is most at risk in the Jini environment. The service exports objects; the lookup locator stores objects, but does not "bring them to life" or execute any of their methods ; but the client brings an external object into its address space and runs it, giving it all of the permissions of a process running in an operating system. The object will run under the permissions of a particular user in a particular directory, with user access to the local file system and network. It could destroy files, make network connections to undesirable sites (or desirable, depending on your tastes!) and download images from them, start processes to send obnoxious mail to anyone in your address book, and generally make a mess of your electronic identity!

A client using multicast search to find service locators will need to grant discovery permission and multicast announcement permission, just like the service:

 permission net.jini.discovery.DiscoveryPermission "*"; permission java.net.SocketPermission "224.0.1.84", "connect,accept"; permission java.net.SocketPermission "224.0.1.85", "connect,accept"; 

RMI connections on random ports may also be needed:

 permission java.net.SocketPermission "*.dstc.edu.au:1024-", "connect,accept" 

In addition, class definitions will probably need to be uploaded so that services can actually run in the client. This is the most serious risk area for the client, as the code contained in these class definitions will be run in the client, and any errors or malicious code will have their effect because of this. The client view of the different levels of trust is shown in Figure 12-1. The client is the most likely candidate to require signed trust certificates since it has the highest trust requirement of the components of a Jini system.

Figure 12-1: Trust levels of the client

Many services will just make use of whatever HTTP server is running on their system, and this will probably be on port 80. Permission to connect on this port can be granted with the following statements:

 permission java.net.SocketPermission "127.0.0.1:80", "connect,accept"; permission java.net.SocketPermission "*.dstc.edu.au:80", "connect,accept"; 

However, while this will allow code to be downloaded on port 80, it may not block some malicious attempts. Any user can start an HTTP server on any port (Windows) or above 1024 (Unix). A service can then set its codebase to whatever port the HTTP server is using. Perhaps these other ports should be blocked, but unfortunately , RMI uses random ports, so these ports need to be open .

So, it is probably not possible to close all holes for hostile code to be downloaded to a client. What you need is a second stage defense: given that hostile code may reach you, set the JDK security so that hostile (or just buggy ) code cannot perform harmful actions in the client.

A fairly minimal policy file suitable for a client could then be as follows :

 grant {     permission net.jini.discovery.DiscoveryPermission "*";     // multicast request address     permission java.net.SocketPermission "224.0.1.85", "connect,accept";     // multicast announcement address     permission java.net.SocketPermission "224.0.1.84", "connect,accept";     // RMI connections     // DANGER     // HTTP connections - this is where external code may come in - careful!!!     permission java.net.SocketPermission "127.0.0.1:1024-", "connect,accept";     permission java.net.SocketPermission "*.canberra.edu.au:1024-",                                           "connect,accept";     permission java.net.SocketPermission "130.102.176.249:1024-", "connect,accept";     // DANGER     // HTTP connections - this is where external code may come in - careful!!!     permission java.net.SocketPermission "127.0.0.1:80", "connect,accept";     permission java.net.SocketPermission "*.dstc.edu.au:80", "connect,accept";     // reading parameters     // like net.jini.discovery.debug!     permission java.util.PropertyPermission "net.jini.discovery.*", "read"; };