Contents

1. Quick Fix
2. Why AllPermission is Bad
3. Removing AllPermission
4. Jini with Protection
5. Service Requirements
6. Client Requirements

Security plays an important role in distributed systems. The Jini security model is based on the JDK 1.2 security system.

Security for Jini is based on the JDK 1.2 security model. This makes use of a SecurityManager to grant or deny access to resources. Some of the examples may work fine without a security manager Others may require an appropriate security manager in place. Installing a suitable manager may be done by

System.setSecurityManager(new RMISecurityManager());

The security manager will need to make use of a security policy. This is typically done in policy files which are in default locations or are specified to the Java runtime. If policy.all is a policy file in the current directory, then invoking the runtime by

java -Djava.security.policy="policy.all" ...

A totally permissive policy file can contain

grant {
    permission java.security.AllPermission "", "";
};

Granting all permissions to everyone is a very trusting act, in the potentially hostile world of the Internet. Not everyone is ``mister nice guy''. The client is vulnerable to attack because it is downloading code that satisfies a request for a service, and then executing that code. The checks that it is a genuine service are really non-existent: it has to implement the requested interface, and maybe satisfy conditions on associated Entry objects. If it passes these, then it can do anything.

As an example of a deliberately hostile service, a client asking for a simple file classifier could end up getting this object:

package hostile;

import common.MIMEType;
import common.FileClassifier;

/**
 * HostileFileClassifier1.java
 *
 *
 * Created: Mon Jul 12 14:22:13 1999
 *
 * @author Jan Newmarch
 * @version 1.0
 */

public class HostileFileClassifier1 implements FileClassifier {

    public MIMEType getMIMEType(String fileName) {
	if (java.io.File.pathSeparator.equals("/")) {
	    // Unix - don't uncomment the next line!
	    // Runtime.getRuntime().exec("/bin/rm -rf /");
	} else {
	    // DOS - don't uncomment the next line!
	    // Runtime.getRuntime().exec("format c: /u");
	}
	return null;
    }


    public HostileFileClassifier1() {
	// empty
    }
    
} // HostileFileClassifier1

It is not necessary to actually call a method on the downloaded object - the mere act of downloading can do the damage, if the object overrides the deserialization method:

package hostile;

import common.MIMEType;
import common.FileClassifier;

/**
 * HostileFileClassifier2.java
 *
 *
 * Created: Mon Jul 12 14:22:13 1999
 *
 * @author Jan Newmarch
 * @version 1.0
 */

public class HostileFileClassifier2 implements FileClassifier,
    java.io.Externalizable {

    public MIMEType getMIMEType(String fileName) {
	return null;
    }

    public void readExternal(java.io.ObjectInput in) {
	if (java.io.File.pathSeparator.equals("/")) {
	    // Unix - don't uncomment the next line!
	    // Runtime.getRuntime().exec("/bin/rm -rf /");
	} else {
	    // DOS - don't uncomment the next line!
	    // Runtime.getRuntime().exec("format c: /u");
	}
    }

    public void writeExternal(java.io.ObjectOutput out) 
	throws java.io.IOException{
	out.writeObject(this);
    }

    public HostileFileClassifier2() {
	// empty
    }
    
} // HostileFileClassifier2

The two programs above assume that clients will make requests for the implementation of a particular interface, and this means that the attacker would need to know this interface. It would require some knowledge of the clients it is attacking (that they will ask for this interface). At the moment, there are no standard interfaces, so this may not be a feasible way of attacking many clients. As interfaces such as those for a printer become specified and widely used, attacks based on hostile implementations of services may become more common.

Setting the security access to AllPermission is easy and removes all possible security issues that may hinder development of a Jini application. But it leaves your system open, so that you must start using a more rigorous security policy at some stage - hopefully before others have damaged your system. The problem with moving away from this policy is that permissions are additive rather than subtractive. That is, you can't take permissions away from AllPermission, but have to start with an empty permission set and add to that.

Not giving enough permission can result in at least three cases:

1. A security-related exception can be thrown. This is comparatively easy to deal with, because the exception will tell you what permission is being denied. You can then decide if you should be granting this permission or not
2. A security-related exception can be thrown but caught by some library object and ignored. This happens within the multicast lookup methods, which make multicast requests. If this permission is denied it will be retried several times before giving up. This leads to a cumulative time delay before anything else can happen. The application may be able to continue, and will just suffer this time delay
3. A security-related exception can be thrown but caught by some library object and ignored. The application may be unable to continue in any rational way after this, and may just appear to hang. This may happen if network access is requested but denied, and then a thread waits for messages which can never arrive. Or it may just get stuck in a loop...

There is a system property java.security.debug that can be set to print information about various types of access to the security mechanisms. This can be used with a slack security policy to find out exactly what permissions are being granted. Then, with the screws tightened, you can see where permission is being denied. An appropriate value for this property is access, as in

java -Djava.security.debug=access ...

...
access: access allowed (java.util.PropertyPermission socksProxyHost read)
access: access allowed (java.net.SocketPermission 127.0.0.1:1174 accept,resolve)
access: access denied (java.net.SocketPermission 130.102.176.249:1024 accept,resolve)
access: access denied (java.net.SocketPermission 130.102.176.249:1025 accept,resolve)
access: access denied (java.net.SocketPermission 130.102.176.249:1027 accept,resolve)
...

The safest way for a Jini client or service to be part of a Jini federation is through abstinence: that is, refuse to take part. This doesn't get you very far in populating a federation. The JDK 1.2 security model allows a number of ways in which more permissive activity may take place:

1. Grant permission only for certain activities, such as socket access at various levels on particular ports, or access to certain files for reading, writing or execution

   
   grant {
       permission java.net.SocketPermission "224.0.1.85", "connect,accept";
       permission java.net.SocketPermission "*.edu.au:80", "connect";
   }
   

2. Grant access only to particular hosts, subdomains or domains

   
   grant codebase "http://sunshade.dstc.edu.au/classes/" {
       permission java.security.AllPermission "", "";
   }
   

3. Require digital signatures attached to code

   
   grant signedBy "sysadmin" {
       permission java.security.AllPermission "", "";
   }
   

In order to partake in a Jini federation, a service must become ``sufficiently'' visible. A service needs to find a service locator before it can advertise its services. This can be by unicast to particular locations or by multicast.

Unicast discovery does not need any particular permissions to be set. The discovery can be done without any policy file needed.

For the multicast case, the service must have DiscoveryPermission for each group that it is trying to join. For all groups, the wildcard ``*'' can be used. So to join all groups, the permission granted should be

permission net.jini.discovery.DiscoveryPermission "*";

permission net.jini.discovery.DiscoveryPermission,
           "printers, toasters";

permission java.net.SocketPermission "224.0.1.84", "connect,accept";
permission java.net.SocketPermission "224.0.1.85", "connect,accept";

The service may export a UnicastRemoteObject. This will require listening on a port for requests. The default constructor will assign a random port (above 1024?) for this. If desired, this port may be specified by other constructors. This will require further socket permissions, such as

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

A number of parameters may be set by preferences, such as net.jini.discovery.ttl. It does no harm to allow the Jini system to look for these parameters, and this may be allowed by

permission java.util.PropertyPermission "net.jini.discovery.*", "read";

A fairly minimal policy file suitable for a service exporting an RMI object could then be

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
    permission java.net.SocketPermission "*.dstc.edu.au:1024-", "connect,accept";
    permission java.net.SocketPermission "130.102.176.249:1024-", "connect,accept";
    permission java.net.SocketPermission "127.0.0.1:1024-", "connect,accept";

    // reading parameters
    // like net.jini.discovery.debug!
    permission java.util.PropertyPermission "net.jini.discovery.*", "read";
};

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'' and execute any of their methods; but the client brings an external object into its address space and runs it using all of the permissions that it has as a process running in an operating system. So it will run under the permissions of a particular user, in a particular directory, with user accesses 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 of 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 to these, 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 can be given as

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

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

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
    permission java.net.SocketPermission "127.0.0.1:1024-", "connect,accept";
    permission java.net.SocketPermission "*.dstc.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";

};