DonŐt sign your code

 

                  Java introduced digital signatures as a way to verify the authenticity of publicly distributed code.  Through a few different methods, a digital signature attached to an archive or JAR is supposed to authenticate the code it is attached to.  The signature is then compared to a database of signatures to ensure that the code was originally distributed by a source that you trust.  This system of authentication is necessary for mobile code.  Most programs will have to execute some privileged operations in order to accomplish their designed task.  These privileged operations are as simple as reading or writing to disk or creating new network connections.  To grant these privileges there must be a formal mechanism to authenticate the source of the code.  Signed code is JavaŐs answer.  Code that is signed and then signature is verified by the end-user against a personal, or public database (VeriSign for example) the Java VM will grant the privileges you have set for that signature source. 

                  Code that is signed will then have all privileges that the user believes the source is entitled to.  By putting your Ňstamp of approvalÓ with your digital signature you are vouching for all code within that JAR.  Hopefully there wonŐt be any security holes anywhere in that JAR that will allow access to outside users.  However, if there are compromising holes, all of the privileges granted by using your digital signature will then be available to that outside user. [8]

                  It is extremely likely that some of your code will have to use privileged operations at some point in order to execute.  These privileges must be granted in a reasonable, secure manner, a digital signature is such a reasonable process.  The privileges granted should be restricted as much as possible, only the blocks of code that are executing privileged operations should be tagged as privileged.  This is possible using the doPrivileged API.  This allows the programmer to only grant privileges to certain sections of their code, revoking those privileges when the block is complete.  One note on this matter is that Java encourages the use of inner classes to implement this code.  As explained earlier this should be avoided, it is possible to implement the doPrivileged API without inner classes and this should be done to insure security. [8] An example of a privileged code block without using anonymous classes is as follows.

class MyClass{

Public void foo() {

                                    É

                  //create a new object with the secure action detailed inside

                                    SecureAction secure = new SecureAction();

                  //execute the secure action as defined in the run() method of

                  //SecureAction

AccessController.doPrivileged(secure);

                                    É

}

}

class SecureAction implements PrivilegedAction {

                  public SecureAction{};

                  public Object run() {

                                    //this is the privileged code

                                    return System.getSecurityManager();

                                    }

}

In this example MyClass does not have the privileges to access the security manager.  To do so privileged code is called to gain access.  This set up limits the privileges of accessing the security manager to precisely where that privilege is needed.  This prevents any code in the class from abusing this privilege.  Specifically methods that may have been compromised due to other security holes.