What is a SecurityManager?

The SecurityManager contains a number of methods that check whether a certain operation is permitted, eg. checkRead, checkWrite, checkPropertyAccess. For example, when you are instantiate an object of the class FileInputStream to open a file, the security manager will be consulted to see if you allowed to do so:

   public FileInputStream(String name) throws FileNotFoundException {
      SecurityManager security = System.getSecurityManager();
      if (security != null) {
         security.checkRead(name);
      }
      fd = new FileDescriptor();
      open(name);
   }

For applications, no security manager is installed and hence the checkRead in the FileInputStream constructor will not be executed and the file is successfully opened. The following program shows that no security manager is installed and thus will output null:

 
public class Main
{
   public static void main(String []args) {
      SecurityManager security = System.getSecurityManager();
      System.out.println(security);
   }
}

To make sure your program is using a default security manager, use the switch -Djava.security.manager when your run your program or do it programmatically by calling System.setSecurityManager.

c:> java Main
null
 
c:> java -Djava.security.manager Main
java.lang.SecurityManager@7032dd38

Look at the output of the following program with and without a security manager:

public class Main
{
   public static void main(String []args) {
      System.out.println(System.getProperty("java.version"));
      System.out.println(System.getProperty("test"));
   }
}

The program tries to output the System properties “java.version” and “test” (a dummy one).

C:> java Main
1.2.2
null

C:> java -Djava.security.manager Main
1.2.2
Exception in thread "main" java.security.AccessControlException: access denied
java.util.PropertyPermission test read)
        at java.security.AccessControlContext.checkPermission(AccessControlCont
xt.java:195)
        at java.security.AccessController.checkPermission(AccessController.java
403)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
        at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1
43)
        at java.lang.System.getProperty(System.java:539)
        at Main.main(Main.java:5)

Notice that without a security manager installed, it runs as we wish. With a default security manager installed, it correctly returns the System property “java.version” but throws an AccessControlException when trying to read the property “test”. Why is that?

First, let’s look at the getProperty method in the System.java source file:

   public static String getProperty(String key) {
      if (security != null) {
         security.checkPropertyAccess(key);
      }
      return props.getProperty(key);
   }

It checks for a security manager and if one exists, it uses checkPropertyAccess to determine whether it is allowed to read the property key that is passed in as an argument. Permissions are granted through policy configuration files. There is a system-wide policy file and a single user policy file. The system-wide policy file is located at JAVA_HOME/lib/security/java.policy and the user policy file can be found at USER_HOME/.java.policy (in my case, I found it in C:WINDOWS). The locations of these two policy files are specified in the file JAVA_HOME/lib/security/java.security (in my case, I found it in C:jdk1.2.2jrelibsecurity). When starting up, the system policy is loaded first and the user policy is added to it. If neither of these policy files are present, a built-in policy is used, which is the same as the sandbox policy.

Now, if you look at a part of the system wide policy file java.policy:

      . . .
 
	// allows anyone to listen on un-privileged ports
	permission java.net.SocketPermission "localhost:1024-", "listen";

	// "standard" properies that can be read by anyone

	permission java.util.PropertyPermission "java.version", "read";
	permission java.util.PropertyPermission "java.vendor", "read";
	permission java.util.PropertyPermission "java.vendor.url", "read";
   
      . . .

To find out how these policy files are structured, look at the document Permissions in the Java 2 SDK or Permissions and Security Policy.

Notice that a permission is granted to read the System property “java.version”. That’s why we can read in this property even with a security manager installed. No permission has been given to read the property “test”, so this results in an Exception.

You can make the JVM use additional policy configuration files with a command-line argument:

   java -Djava.security.manager -Djava.security.policy=mypolicyfile Main

For example, we could add an extra permission to read the property “test”.

mypolicyfile:

grant {
   permission java.util.PropertyPermission "test", "read";
};

result:

C:>java -Djava.security.manager -Djava.security.policy=mypolicyfile Main
1.2.2
null

mypolicyfile can be either made with a simple text editor or with the graphical JDK tool policytool.

If you want the JVM use only your policy file and not the system-wide nor the user policy, use a double equal sign:

C:>java -Djava.security.manager -Djava.security.policy==mypolicyfile Main

This would result in an exception when trying to read the system property “java.version”.

The policy file can be highly customized. It should be structured as follows:

   grant signedBy "signer_name", codeBase "URL", 
      principal principal_class_name "principal_name",
      principal principal_class_name "principal_name",
      ... {
      permission permission_class_name "target_name", "action", 
         signedBy "signer_name";
      permission permission_class_name "target_name", "action", 
         signedBy "signer_name";
      ...
   };

For more information on policy file syntax look at the document Default Policy Implementation and Policy File Syntax

( Note: the principal entry is useful for assigning permission based on who is running the code as opposed to where the code is coming from or who signed it, look at the JAAS category for more information. )

For example, to only grant permissions to our Main class located in C: we would write:

grant codeBase "file:C:/" {
   permission java.util.PropertyPermission "test", "read";
};

Running our Main in C:test would result in an AccessControlException: Access Denied.

Encrypting/decrypting using RC2

RC2 stands for Rivest’s Code 2. More information can be found on the RSA Security site.

Main.java:

import javax.crypto.spec.*;
import java.security.*;
import javax.crypto.*;
 
public class Main
{
   public static void main(String []args) throws Exception {
      String toEncrypt = "The shorter you live, the longer you're dead!";
 
      System.out.println("Encrypting...");
      byte[] encrypted = encrypt(toEncrypt, "password");
 
      System.out.println("Decrypting...");
      String decrypted = decrypt(encrypted, "password");
    
      System.out.println("Decrypted text: " + decrypted);
   } 
 
   public static byte[] encrypt(String toEncrypt, String key) throws Exception {
      // create a binary key from the argument key (seed)
      SecureRandom sr = new SecureRandom(key.getBytes());
      KeyGenerator kg = KeyGenerator.getInstance("RC2");
      kg.init(sr);
      SecretKey sk = kg.generateKey();
 
      // create an instance of cipher
      Cipher cipher = Cipher.getInstance("RC2");
 
      // initialize the cipher with the key
      cipher.init(Cipher.ENCRYPT_MODE, sk);
 
      // enctypt!
      byte[] encrypted = cipher.doFinal(toEncrypt.getBytes());
 
      return encrypted;
   }
 
   public static String decrypt(byte[] toDecrypt, String key) throws Exception {
      // create a binary key from the argument key (seed)
      SecureRandom sr = new SecureRandom(key.getBytes());
      KeyGenerator kg = KeyGenerator.getInstance("RC2");
      kg.init(sr);
      SecretKey sk = kg.generateKey();
 
      // do the decryption with that key
      Cipher cipher = Cipher.getInstance("RC2");
      cipher.init(Cipher.DECRYPT_MODE, sk);
      byte[] decrypted = cipher.doFinal(toDecrypt);
 
      return new String(decrypted);
   }
}

(tested with the BouncyCastle JCE provider, http://www.bouncycastle.org)

Controlling permissions with a JApplet

It is important that you have installed the JRE1.3 on your machine, that includes the Java 1.3 plug-in.

An JApplet runs by default in a security sandbox, an environment where it has no permission to do anything that might harm the client’s machine.

Consider the following applet.

WriteFile.java:

import javax.swing.*;
import java.awt.*;
import java.io.*;
 
public class WriteFile extends JApplet {
   public void paint(Graphics g) {
      String filename = "/tmp/esusfoo";
      if (System.getProperty("os.name").indexOf("Windows") != -1) {
         filename = "C:\esusfoo";
      }
 
      try {
         BufferedWriter bw = new BufferedWriter(new FileWriter(filename));
         bw.write("The sun is green and the grass shines.n");
         bw.flush();
         bw.close();
 
         g.drawString("File " + filename + " created!", 10, 10);
      }
      catch (Exception e) {
         g.drawString(""+e, 10, 10);
      }
   }
}

WriteFile.html (generated with Sun’s HTMLConverter tool):

<html>
<body>
 
<!--"CONVERTED_APPLET"-->
<!-- CONVERTER VERSION 1.0 -->
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
WIDTH = 700 HEIGHT = 100  
codebase="http://java.sun.com/products/plugin/1.3/jinstall-13-win32.cab#Version=1,3,0,0">

<PARAM NAME = CODE VALUE = WriteFile >
 
<PARAM NAME="type" VALUE="application/x-java-applet;version=1.3">
<COMMENT>
<EMBED type="application/x-java-applet;version=1.3" java_CODE = WriteFile 
WIDTH = 700 HEIGHT = 100   
pluginspage="http://java.sun.com/products/plugin/1.3/plugin-install.html">
<NOEMBED></COMMENT>
 
</NOEMBED></EMBED>
</OBJECT>
 
<!--
<APPLET  CODE = WriteFile WIDTH = 700 HEIGHT = 100 >
 
 
</APPLET>
-->
<!--"END_CONVERTED_APPLET"-->
 
 
</body>
</html>

When you run this JApplet, you’ll get a security exception.
Check it out for yourself at http://www.esus.com/applets/WriteFile.html.

So what do we need to do to make this work?

You will have to explicitely give access to that applet to use resources it is normally not permitted to. To do so, one requirement is to sign our applet. The following procedure shows you how to sign an applet. You will need to have a certificate, either one you create yourself (a self-signed applet) or one that you have bought from a certificate authority like VeriSign or Thawte. For now, I’ll create one myself.

Create a certificate with keytool (JDK tool introduced in JDK1.2.2):

C:certificateapplet> keytool -genkey -alias esustest -keyalg rsa
Enter keystore password:  esuspass
What is your first and last name?
  [Unknown]:  Joris Van den Bogaert
What is the name of your organizational unit?
  [Unknown]:  ESUS Team
What is the name of your organization?
  [Unknown]:  ESUS, Inc.
What is the name of your City or Locality?
  [Unknown]:  Meerbeek
What is the name of your State or Province?
  [Unknown]:
What is the two-letter country code for this unit?
  [Unknown]:  BE
Is <CN=Joris Van den Bogaert, OU=ESUS Team, O="ESUS, Inc.", L=Meerbeek, ST=Unkno
wn, C=BE> correct?
  [no]:  yes

Enter key password for <esustest>
        (RETURN if same as keystore password):

C:certificateapplet>

(Note: if you haven’t used keytool before, just make up a password) Here we have created a RSA key with the name esustest. Now look in your home directory, a file should have been created called .keystore:

C:certificateapplet> dir c:windows.key*

 Volume in drive C has no label
 Volume Serial Number is 1380-0FE3
 Directory of C:WINDOWS

KEYSTO~1             1,382  07-21-01  1:28a .keystore
         1 file(s)          1,382 bytes
         0 dir(s)     164,356,096 bytes free

To see that the key has been added to the store:

C:certificateapplet> keytool -list
Enter keystore password:  esuspass

Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry:

esustest, Sat Jul 21 01:28:48 CEST 2001, keyEntry,
Certificate fingerprint (MD5): 88:09:3D:97:3A:7B:91:AD:4B:01:B8:3E:40:B8:C6:2A

Now let’s create a JAR file from our applet:

C:certificateapplet>jar cvf WriteFile.jar WriteFile.class
added manifest
adding: WriteFile.class(in = 1250) (out= 732)(deflated 41%)

The jar has been created:

C:certificateapplet> dir *.jar

 Volume in drive C has no label
 Volume Serial Number is 1380-0FE3
 Directory of C:certificateapplet

WRITEF~1 JAR         1,196  07-21-01  1:38a WriteFile.jar
         1 file(s)          1,196 bytes
         0 dir(s)     164,347,904 bytes free

Now we can sign that JAR file with our generated keypair as follows:

C:certificateapplet> jarsigner WriteFile.jar esustest
Enter Passphrase for keystore: esuspass

C:certificateapplet> dir *.jar

 Volume in drive C has no label
 Volume Serial Number is 1380-0FE3
 Directory of C:certificateapplet

WRITEF~1 JAR         2,348  07-21-01  1:38a WriteFile.jar
         1 file(s)          2,332 bytes
         0 dir(s)     164,347,904 bytes free

Notice the size of our original JAR and the new digitally signed JAR! We can verify the JAR as follows:


C:certificateapplet>jarsigner -verify -certs -verbose WriteFile.jar

         136 Sat Jul 21 05:22:54 CEST 2001 META-INF/MANIFEST.MF
         189 Sat Jul 21 05:22:56 CEST 2001 META-INF/ESUSTEST.SF
         980 Sat Jul 21 05:22:56 CEST 2001 META-INF/ESUSTEST.RSA
           0 Sat Jul 21 05:22:16 CEST 2001 META-INF/
smk     1213 Sat Jul 21 05:21:10 CEST 2001 WriteFile.class

      X.509, CN=Joris Van den Bogaert, OU=ESUS Team, O="ESUS, Inc.", L=Meerbeek,
 ST=Unknown, C=BE (esustest)


  s = signature was verified
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
  i = at least one certificate was found in identity scope

jar verified.

Notice the files that have been added to the JAR file:ESUSTEST.SF and ESUSTEST.RSA. SF stands for Signature File and it includes the filename (WriteFile.class), the name of the algorithm used (RSA) and the digest value. Test it out for yourself:

C:certificateapplet>jar -xf WriteFile.jar META-INF/ESUSTEST.SF

C:certificateapplet>dir

 Volume in drive C has no label
 Volume Serial Number is 1380-0FE3
 Directory of C:certificateapplet

.              <DIR>        07-21-01 12:32a .
..             <DIR>        07-21-01 12:32a ..
WRITEF~1 JAV           728  07-21-01  1:14a WriteFile.java
WRITEF~1 CLA         1,250  07-21-01  1:14a WriteFile.class
WRITEF~1 HTM            95  07-21-01 12:47a WriteFile.html
WRITEF~1 JAR         2,348  07-21-01  1:38a WriteFile.jar
META-INF       <DIR>        07-21-01  1:45a META-INF
         4 file(s)          4,405 bytes
         3 dir(s)     164,265,984 bytes free

C:certificateapplet>cd meta-inf

C:certificateappletMETA-INF>dir

 Volume in drive C has no label
 Volume Serial Number is 1380-0FE3
 Directory of C:certificateappletMETA-INF

.              <DIR>        07-21-01  1:45a .
..             <DIR>        07-21-01  1:45a ..
ESUSTEST SF            189  07-21-01  1:45a ESUSTEST.SF
         1 file(s)            189 bytes
         2 dir(s)     164,265,984 bytes free

C:certificateappletMETA-INF> type esustest.sf
Signature-Version: 1.0
SHA1-Digest-Manifest: Zy9znt1bwLpXeGV+pr+rkaHU4Rw=
Created-By: 1.2.2 (Sun Microsystems Inc.)

Name: WriteFile.class
SHA1-Digest: JFrqA7g/ZadrRHkJmXgsCTwZRSo=

The other file that has been added to the JAR is ESUSTEST.RSA. This is the Signature Block File It contains the certificate or certificate chain.

Now we’re ready to deploy our signed applet and see if that changed the situation. Let’s first modify our HTML file so that it uses the JAR file instead of the class file.

WriteFile2.html:

<html>
<body>
This file will create a file on your drive called esusfoo.  
Under Windows it will be located in C:, under unix it will be located in /tmp.  
If you do not want this to happen, click DENY when your browser asks you 
for additional permissions.
<br><br><br><br>
<!--"CONVERTED_APPLET"-->
<!-- CONVERTER VERSION 1.3 -->
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
WIDTH = 700 HEIGHT = 100  
codebase="http://java.sun.com/products/plugin/1.3/jinstall-13-win32.cab#Version=1,3,0,0">
<PARAM NAME = CODE VALUE = "WriteFile.class" >
<PARAM NAME = ARCHIVE VALUE = "WriteFile.jar" >

<PARAM NAME="type" VALUE="application/x-java-applet;version=1.3">
<PARAM NAME="scriptable" VALUE="false">
<COMMENT>
<EMBED type="application/x-java-applet;version=1.3"  CODE = "WriteFile.class" 
ARCHIVE = "WriteFile.jar" WIDTH = 700 HEIGHT = 100  scriptable=false 
pluginspage="http://java.sun.com/products/plugin/1.3/plugin-install.html">
<NOEMBED></COMMENT>

</NOEMBED></EMBED>
</OBJECT>

<!--
<APPLET CODE = "WriteFile.class" ARCHIVE = "WriteFile.jar" WIDTH = 700 HEIGHT = 100>


</APPLET>
-->
<!--"END_CONVERTED_APPLET"-->


</body>
</html>

Upload the files to your webserver and try it out! You can also try it out here:
http://www.esus.com/applets/WriteFile2.html.

With both Netscape and IE, you’ll get the following window:




Hmm, it doesn’t really create a file, does it? Well, earlier version of the plug-in (JDK1.2.2) would actually ask you if you want to grant extra permissions. But from the 1.3 plugin onwards, self-signed applets (like our WriteFile.jar) will need extra work! If you would have signed your applet with a certificate you bought from a recognized standard root CA, like VeriSign or Thawte, the browser would ask you if you want to grant additional permissions. Check out http://java.sun.com/products/plugin/1.3/docs/nsobjsigning.html!

Just like anyone else, I don’t have no money :) So for the time being, I won’t buy such a certificated from a trusted CA. But I’ll show you a way to have your applet run anyway (useful for testing purposes). It is important to realize that in order to do so, you must have access to the client’s machine(s) onto which you want to deploy your applet.

What happens when you download a signed applet is this: the browser downloads the JAR file and checks whether it is signed. If it is, it will check the security policy configuration file whether the “usePolicy” RuntimePermission is set. There are two policy files, a system-wide one, (JRE_HOME/lib/security/java.policy) and a user specific one (USER_HOME/.java.policy). In my case, my system-wide one is at C:Program FilesJavaSoftJRE1.3.1libsecurity and my user one is at C:Windows.java.policy. When the plug-in starts, it will concatenate both of them together and use them as a security policy for the rest of the session. If the usePolicy permission is set, security is controlled based on the permissions that are set in the policy files, even if you have an RSA signed applet signed by a trusted authority that wants full control over your client’s machine. This allows you to have finer-grained security control over what your signed applets are able to do.

Let’s change our policy file to grant the permission to write to the local file c:esusfoo. Add the following lines of code to your .java.policy file:

grant {
   permission java.io.FilePermission "C:${/}esusfoo", "write";
};

and test out http://www.esus.com/applets/WriteFile2.html again.

You get the following error:



Click OK, the file will be created anyway, since you granted that permission explicitely in your policy file.

To get rid of that annoying error, define the extra permission “usePolicy” in your policy file:

grant {
   permission java.lang.RuntimePermission "usePolicy";
   permission java.io.FilePermission "C:${/}esusfoo", "write";
};

Try out the applet again! No errors!

Let’s modify the applet a bit so that it also tries to write to a file c:esusfoo2. The new applet look like this.

WriteTwoFiles.java:

import javax.swing.*;
import java.awt.*;
import java.io.*;
 
public class WriteTwoFiles extends JApplet {
   public void paint(Graphics g) {
      String filename1 = "/tmp/esusfoo";
      String filename2 = "/tmp/esusfoo2";
      if (System.getProperty("os.name").indexOf("Windows") != -1) {
         filename1 = "C:\esusfoo";
         filename2 = "C:\esusfoo2";
      }
 
      BufferedWriter bw;
      try {
         bw = new BufferedWriter(new FileWriter(filename1));
         bw.write("The sun is green and the grass shines.n");
         bw.flush();
         bw.close();
 
         g.drawString("File " + filename1 + " created!", 10, 10);
      }
      catch (Exception e) {
         g.drawString(""+e, 10, 10);
      }
 
      try { 
         bw = new BufferedWriter(new FileWriter(filename2));
         bw.write("The sun shines and the grass is green.n");
         bw.flush();
         bw.close();
 
         g.drawString("File " + filename2 + " created!", 10, 50);
      }
      catch (Exception e) {
         g.drawString(""+e, 10, 50);
      }
   }
}

Sign the jar file as described above:

C:certificateapplet> jar cvf WriteTwoFiles.jar WriteTwoFiles.class
added manifest
adding: WriteTwoFiles.class(in = 1458) (out= 822)(deflated 43%)

C:certificateapplet> jarsigner WriteTwoFiles.jar esustest
Enter Passphrase for keystore: esuspass

WriteTwoFiles.html:

<html>
<body>
<br>
<!--"CONVERTED_APPLET"-->
<!-- CONVERTER VERSION 1.3 -->
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
WIDTH = 700 HEIGHT = 100  
codebase="http://java.sun.com/products/plugin/1.3/jinstall-13-win32.cab#Version=1,3,0,0">
<PARAM NAME = CODE VALUE = "WriteTwoFiles.class" >
<PARAM NAME = ARCHIVE VALUE = "WriteTwoFiles.jar" >

<PARAM NAME="type" VALUE="application/x-java-applet;version=1.3">
<PARAM NAME="scriptable" VALUE="false">
<COMMENT>
<EMBED type="application/x-java-applet;version=1.3"  
CODE = "WriteTwoFiles.class" ARCHIVE = "WriteTwoFiles.jar" WIDTH = 700 HEIGHT = 100  
scriptable=false pluginspage="http://java.sun.com/products/plugin/1.3/plugin-install.html">
<NOEMBED></COMMENT>

</NOEMBED></EMBED>
</OBJECT>

<!--
<APPLET CODE = "WriteTwoFiles.class" ARCHIVE = "WriteTwoFiles.jar" WIDTH = 700 HEIGHT = 100>


</APPLET>
-->
<!--"END_CONVERTED_APPLET"-->


</body>
</html>

If you run this signed applet (http://www.esus.com/applets/WriteTwoFiles.html), using the same modified policy file, esusfoo was successfully accessed but, a AccessControlException is thrown in accessing esusfoo2, as expected.

One more problem: the extra permissions to write to esusfoo and esusfoo2 are granted to all applets. You can fine-tune your policy configuration file with signedBy and/or codeBase. With signedBy, you can specify the keystore entry that contains the public key so that verification of the signed JAR file is possible. The runtime system then verifies the association of the private key with which the JAR file was signed with the public key of the specified entry in the keystore. codeBase specifies that the permissions in this grant entry are only applicable to signed applets coming from a particular code source.

Because we’re using a self-signed applet, we need to import our certificate in the keystore of the plug-in. The following steps show you how to:

  1. export the certificate to a file:
    C:certificateapplet> keytool -export -alias esustest -file esustest.cer
    Enter keystore password:  esuspass
    Certificate stored in file <esustest.cer>
    
  2. copy esustest.cer to the directory that contains the file cacerts:
    C:certificateapplet> copy esustest.cer "c:program filesjavasoftjre1.3.1libsecurity
            1 file(s) copied
    
  3. make a backup of cacerts:
    C:Program FilesJavaSoftJRE1.3.1libsecurity>copy cacerts cacerts.bak
            1 file(s) copied
    
  4. import the certificate into the cacerts keystore:
    C:Program FilesJavaSoftJRE1.3.1libsecurity>keytool -import -alias esustest
     -keystore cacerts -file esustest.cer
    Enter keystore password:  changeit
    Owner: CN=Joris Van den Bogaert, OU=ESUS Team, O="ESUS, Inc.", L=Meerbeek, ST=Un
    known, C=BE
    Issuer: CN=Joris Van den Bogaert, OU=ESUS Team, O="ESUS, Inc.", L=Meerbeek, ST=U
    nknown, C=BE
    Serial number: 3b58beaa
    Valid from: Sat Jul 21 01:28:42 CEST 2001 until: Fri Oct 19 01:28:42 CEST 2001
    Certificate fingerprints:
             MD5:  88:09:3D:97:3A:7B:91:AD:4B:01:B8:3E:40:B8:C6:2A
             SHA1: 6A:A1:0E:19:45:91:07:97:B0:75:BE:BB:79:91:2A:1A:27:F2:36:93
    Trust this certificate? [no]:  yes
    Certificate was added to keystore
    

    (Note: the initial password for the cacerts file is changeit as specified in the documentation)

Our self-signed certificate is now added to our database.

Run WriteTwoFiles again. Notice that now you’ll get the following dialog box:




This dialog box would also show up if your applet was signed by a certificate assigned by a VeriSign or Thawte type trusted CA.

Now change to policy file for more fine-grained control:

grant signedBy "esustest", codeBase "http://www.esus.com/applets/WriteTwoFiles.jar" {
   permission java.lang.RuntimePermission "usePolicy";
   permission java.io.FilePermission "C:${/}esusfoo", "write";
   permission java.io.FilePermission "C:${/}esusfoo2", "write";
};

Rolling your own SecurityManager

If you look in the source code for FileOutputStream, you’ll notice that, before a file is created and written to, a check is performed to see whether it is allowed to do so.

java.io.FileOutputStream.java:

    public FileOutputStream(String name, boolean append)
        throws FileNotFoundException
    {
	SecurityManager security = System.getSecurityManager();
	if (security != null) {
	    security.checkWrite(name);
	}
      . . .

If no SecurityManager is installed, System.getSecurityManager will return null and no security checks will be performed. We can see that happening by just creating an application that writes to a file.

Main.java:

import java.io.*;
 
public class Main {
   public static void main(String []args) throws Exception {
      FileOutputStream fos = new FileOutputStream("testfile.txt");
      fos.write("hey".getBytes());
      fos.close();
      System.out.println("testfile.txt successfully written!");
   }
}

Running this code with java Main will write the file testfile.txt. If you run this code with java -Djava.security.manager Main, notice that an exception is thrown:

 Exception in thread "main" java.security.AccessControlException: access denied (
java.io.FilePermission testfile.txt write)
        at java.security.AccessControlContext.checkPermission(AccessControlConte
xt.java:195)
        at java.security.AccessController.checkPermission(AccessController.java:
403)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
        at java.lang.SecurityManager.checkWrite(SecurityManager.java:958)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:96)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:62)
        at Main.main(Main.java:5)

We could write our own SecurityManager that allows to write to testfile.txt and restricts everything else to the security sandbox.

MySecurityManager.java:

import java.io.*;
 
public class MySecurityManager extends SecurityManager {
   public void checkWrite(String file) {
      if (!file.equals("testfile.txt")) {
         throw new SecurityException("Only allowed to write to file testfile.txt.");
      }
   }
}

Now we can use our new security manager by either specifying it at command line:

C:> java -Djava.security.manager=MySecurityManager Main
testfile.txt successfully written!

or by doing so programmatically:

import java.io.*;
 
public class Main {
   public static void main(String []args) throws Exception {
      System.setSecurityManager(new MySecurityManager()); 
 
      FileOutputStream fos = new FileOutputStream("testfile.txt");
      fos.write("hey".getBytes());
      fos.close();
      System.out.println("testfile.txt successfully written!");
   }
}

Running:

C:> java Main
testfile.txt successfully written!

A custom security manager can be useful in JDK1.1 applications. However, it becomes a real pain (lots of programming) when you want to specify security restrictions based on who is running the code or where the code is coming from.

From JDK1.2, you can use policy files to customize the security manager in a fine-grained fashion. Let’s use the original program:
Main.java:

import java.io.*;
 
public class Main {
   public static void main(String []args) throws Exception {
      FileOutputStream fos = new FileOutputStream("testfile.txt");
      fos.write("hey".getBytes());
      fos.close();
      System.out.println("testfile.txt successfully written!");
   }
}

and write a policy file that allows writing to only the file testfile.txt:
mypolicy.txt

grant {
   permission java.io.FilePermission "testfile.txt", "write";
};

Run the code and specify the policy file to be used at runtime:

C:> java -Djava.security.policy=mypolicy.txt -Djava.security.manager Main
testfile.txt successfully written!

Install the free Bouncy Castle JCE Provider

Bouncy Castle is a free provider for JCE. These following steps will explain how to add this security provider.

  1. Download the latest release for your JDK version at http://www.bouncycastle.org/latest_releases.html
  2. Extract the zip file in your home directory
  3. BouncyCastle doens’t come with a JAR file. In order to add it to the bootclasspath, create one:
         c:jce-jdk12-107classes> jar cvf bouncycastle.jar *
         c:jce-jdk12-107classes> copy bouncycastle.jar c:jdk1.2.2jrelibext
    
  4. Go to your JAVA_HOME/jre/lib/security directory and edit the file java.security. Look at the configuration, in my case it says something like:
       security.provider.1=sun.security.provider.Sun
       security.provider.2=com.sun.crypto.provider.SunJCE
    

    Add the line security.provider.3=org.bouncycastle.jce.provider.BouncyCastleProvider

  5. Run one of the examples to see if it is working (eg. How do I crypt/decrypt a message with the Blowfish algorithm?)

Update:

This information is outdated. Now, you can download JAR versions for your JDK version.

For 1.3.1, I downloaded jce-jdk13-118.jar and bcprov-jdk13-118.jar and added them to my classpath (you can also put them in jdk1.3.1/jre/lib/ext and NOT add them to your classpath).

You can add a static provider to jdk1.3.1/jre/lib/security/java.security as described above or you can do this programmatically in your code:

...
   java.security.Provider provider = new org.bouncycastle.jce.provider.BouncyCastleProvider();
   Security.addProvider(provider);

Encrypting/decrypting using RC4

RC4 (Ron’s Code) is a symmetric key encryption algorithm. Developed in 1987 by Ronald Rivest, it is used in SSL and many applications such as Lotus Notes and Oracle Secure SQL.

RC4 is a stream cipher, meaning that it encrypts one byte at a time. With RC4, the key is variable, from 1 to 2048 bits. RC4 is about 10 times as fast as DES. The algorithm is small and simple to implement. Here’s an unreadable version of it written in Perl.

Main.java:

import javax.crypto.spec.*;
import java.security.*;
import javax.crypto.*;
 
public class Main
{
   private static String algorithm = "RC4";
 
   public static void main(String []args) throws Exception {
      String toEncrypt = "The shorter you live, the longer you're dead!";
 
      System.out.println("Encrypting...");
      byte[] encrypted = encrypt(toEncrypt, "password");
 
      System.out.println("Decrypting...");
      String decrypted = decrypt(encrypted, "password");
    
      System.out.println("Decrypted text: " + decrypted);
   } 
 
   public static byte[] encrypt(String toEncrypt, String key) throws Exception {
      // create a binary key from the argument key (seed)
      SecureRandom sr = new SecureRandom(key.getBytes());
      KeyGenerator kg = KeyGenerator.getInstance(algorithm);
      kg.init(sr);
      SecretKey sk = kg.generateKey();
 
      // create an instance of cipher
      Cipher cipher = Cipher.getInstance(algorithm);
 
      // initialize the cipher with the key
      cipher.init(Cipher.ENCRYPT_MODE, sk);
 
      // enctypt!
      byte[] encrypted = cipher.doFinal(toEncrypt.getBytes());
 
      return encrypted;
   }
 
   public static String decrypt(byte[] toDecrypt, String key) throws Exception {
      // create a binary key from the argument key (seed)
      SecureRandom sr = new SecureRandom(key.getBytes());
      KeyGenerator kg = KeyGenerator.getInstance(algorithm);
      kg.init(sr);
      SecretKey sk = kg.generateKey();
 
      // do the decryption with that key
      Cipher cipher = Cipher.getInstance(algorithm);
      cipher.init(Cipher.DECRYPT_MODE, sk);
      byte[] decrypted = cipher.doFinal(toDecrypt);
 
      return new String(decrypted);
   }
}

Getting the current NT/2000/XP user using JAAS

Note: if you are using a JDK less than 1.4, make sure you have downloaded the JAAS class libraries and the sample authentication module for Windows at http://java.sun.com/products/jaas/index-10.html. Put jaas.jar and jaasmod.jar in your classpath.

Main.java:

import com.sun.security.auth.module.NTSystem;
 
public class Main {
   public static void main(String []args) {
      NTSystem ntSystem = new NTSystem();
      System.out.println(ntSystem.getName());
   }
}

outputs on my machine:

C:myjaastest>java -Djava.library.path=c:javatoolsjaasmod1_0lib Main
esus

To get other NT properties:

import com.sun.security.auth.module.NTSystem;
import java.util.Arrays;

public class Main {
   public static void main(String []args) {
      NTSystem ntSystem = new NTSystem();
      System.out.println(ntSystem.getName());
      System.out.println(ntSystem.getDomain());
      System.out.println(ntSystem.getDomainSID());
      System.out.println(Arrays.asList((Object[])ntSystem.getGroupIDs()));
      System.out.println(ntSystem.getImpersonationToken());
      System.out.println(ntSystem.getPrimaryGroupID());
      System.out.println(ntSystem.getUserSID());
   }
}

outputs:

C:myjaastest>java -Djava.library.path=c:javatoolsjaasmod1_0lib Main
esus
WORKGROUP

[S-1-5-21-3978503659-2915903831-1203752577-513, S-1-1-0, S
-1-5-32-544, S-1-5-32-545, S-1-5-5-0-51662, S-1-2-0, S-1-5
-4, S-1-5-11]
1252
S-1-5-21-3978503659-2915903831-1203752577-513
S-1-5-21-3978503659-2915903831-1203752577-1007