This is a brief rundown of especially the commands described in the [http://java.sun.com/docs/books/tutorial/security1.2/index.html Java Security Trail]. For full understanding, read the trail.

Policy files

Security policies are stored in "policy files". These need to be included either by adding to the $JAVA_HOME/lib/security/java.security file or by using the -Djava.security.policy=<policyfile>. For the former, add a line policy.url.n=<policyfile> where n is an integer that has not been used in the java.security file before.

The policy files can be edited using the policytool program that comes with Java. The trail describes how the 1.5 tool works, the 1.6 tool has less keystore-related functionality.

Permissions to do "stuff" can be granted either to code from a particular "CodeBase" (URL of the files) or to code signed by a certificate. For a CodeBase, permission can be granted to a URL and all subdirectories thereof by adding '-' to the URL, e.g. http://netarkivet.dk/- to specify permissions for anything from netarkivet.dk.

Permissions are organized by class, e.g. FilePermission controls read/write/execute permissions for files. All permissions have a target, e.g. a file or directory for FilePermission. The syntax of the target is defined by the permission class. For FilePermission, it is simply a file. Question: What about subdirectories?

The Trail mentions that on Unix there may be some [http://java.sun.com/docs/books/tutorial/security/tour1/step3.html DNS-related hacks required]. I didn't find this necessary on an Ubuntu 7.10 box.

Java applets by default have a security manager installed, but Java applications do not. To use a security manager, run Java with with -Djava.security.manager.

[http://java.sun.com/docs/books/tutorial/security/tour2/examples/java.policy Default policy] is to let anyone listen to any port > 1024 and to allow reading some specific properties like java.vendor.name, os.name etc.

The policy tool is fairly simple to use. For example, to create a file read policy for code from a given URL, run policytool, click Add policy entry, enter the URL at CodeBase, click Add permission, select FilePermission, enter the relevant file at Target, select read under actions, click Ok, click Done, pick Save menu item and save the policy under whatever name you like.

Certificates

We will be using certificates at least to allow our code to 1) write new files to the bitarchive, and 2) perform the correction action. Other people's code may not be given the rights to even create files, they may only get to write to a given OutputStream. We won't need an infrastructure to accept arbitrary certificates, just to accept our own, which can be done during deployment.