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.
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.TestGUINodeor
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.
-Djava.security.manager
:
java -Djava.security.manager drm.test.TestGUINodeor
java -Djava.security.manager drm.server.NakedNodeThis 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.
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.TestGUINodeor
java -Djava.security.manager drm.server.NakedNodeThen 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 };