Security

Introduction

An agent architecture in general raises many security problems. This is in connection with the fact that agents run program code that was written by unknown people so the quality and friendliness is not guaranteed.

The situation is almost the same as in the case of applets. The only difference is that with agents one doesn't have a clearly and securely identifiable code source. In the case of applets this code source is the URL which the applet was downloaded from. However signatures can be applied in both cases to identify the creator of the code.

Our architecture is based on the possibilities provided by java. In the following it will not be assumed that the reader is familiar with the basic concepts of the java security architecture when describing the step-by-step procedure to start up a node with security support. However to be able to really make use of the possibilities it is essential that one has a basic understanding of these concepts. The webpage http://java.sun.com/j2se/1.3/docs/guide/security/index.html offers a very good introduction.

No protection

In the simplest case there is no protection and the node and the agents too are run just like any other application under the local operating system. When starting the java virtual machine without any special options or configuration settings this is the default behaviour. Thus saying

java drm.test.TestGUINode
or
java drm.server.NakedNode
(of course an eventual -classpath argument may be present) starts a node without the security features and then any agent arriving at the node will have equal rights to all the applications of the operating system. They can open, write, delete files, they can open network connections, change system properties, etc. Obviously this is not desirable.

Sandbox model

The sandbox model means that the agents are granted only the default minimal permissions which are just enough for running. However the agents can send messages and launch new agents trough library functions provided by the node. This offers a safe and controlled way of accessing resources. Implementing the sandbox model is easy. To do this, first of all the node must be started with the default security manager installed. For the sun j2 sdk package the standard option to do this is -Djava.security.manager:
java -Djava.security.manager drm.test.TestGUINode
or
java -Djava.security.manager drm.server.NakedNode
This is not enough however. In fact it is too much because this way the whole node is run as an applet in the sandbox not only the agents. But the node needs application rights. To give the node application rights you have to edit (or create) a policy file. The easiest thing is to edit the default policy file (${user.home}/.java.policy). Another possibility is to create a new one (say my.policy) and using the option -Djava.security.policy=my.policy

To the policy file you should add a grant entry which looks like

grant codeBase "file:/home/garfield/drm/-" {
        permission java.security.AllPermission;
};
Don't forget the - at the end of the codeBase! For /home/garfield/drm you have to substitute the directory where you installed the class files (or the jar archive(s)) of the node.

Important! The directory where the system stores temporary files, including downloaded jar files (defined by the java system property java.io.tmpdir) must not be under this directory (and thus in this codeBase) otherwise the agents will be granted the application permissions too which makes the security manager useless. It is safe not to change the default value of java.io.tmpdir as it is very unlikely to be under the drm installation directory.

More fine-grained security control

Due to the implementation of mobility in our architecture it is relatively easy to apply the security concepts originally developed for applets. The classes needed to run the agents are downloaded in one step as a jar archive and copied to the temporary directory (maybe to subdirectories under this directory). The name of this directory defaults to java.io.tmpdir. The user can change this system property if necessary at JVM startup. Using this directory as a codeBase it is possible to grant fine-grained permissions to the agents. Applying also signatures it becomes possible to control agents signed by different parties differently. We do not go into the details, those who know the possibilities of the java security model already understand the situation. To give a simple example (without using signatures) let us assume that the node will be started using
java -Djava.security.manager drm.test.TestGUINode
or
java -Djava.security.manager drm.server.NakedNode
Then adding the following to a default policy file will allow fine-grained control of the agent's permissions:
grant codeBase "file:/home/garfield/drm/-" {
        permission java.security.AllPermission;
};

grant codeBase "file:${java.io.tmpdir}/-" {
	// agents' permissions 
	// come here
};