Java security sandbox

http://www.artima.com/insidejvm/ed2/security15.html

The fundamentalcomponents responsible for Java's sandbox are:

• the class loader architecture
• the class file verifier
• safety features built into the Java virtual machine (and the language)
• the security manager and the Java API

One of the greatest strengths of Java's sandbox security model is thattwo of these components, the class loader and security manager, arecustomizable. By customizing these components, you can create a customizedsecurity policy for a Java application. 

In Java's sandbox, theclass loader architecture is the first line of defense. It is the class loader,after all, that brings code into the Java virtual machine--code that could behostile or buggy. The class loader architecture contributes to Java's sandboxin three ways:

1.     it prevents malicious code from interfering withbenevolent code,

2.     it guards the borders of the trusted classlibraries, and

3.     it places code into categories (called protectiondomains) that will determine whichactions the code will be allowed to take.

AccessController'scheckPermission

The basic algorithmimplemented by the AccessController'scheckPermission() method makes certain thatevery frame on the call stack has permission to perform the potentially unsafeaction.

To enable trusted code toperform actions for which less trusted code farther down the call stack may nothave permission to do, theAccessController class offers four overloaded static methods named doPrivileged().Each of these methods accepts as a parameter an object that implements eitherthejava.security.PrivilegedAction orjava.security.PrivilegedExceptionAction interface. 

PolicyFile

keystore "ijvmkeys";grant signedBy "friend" {    permission java.io.FilePermission "question.txt", "read";    permission java.io.FilePermission "answer.txt", "read";};grant signedBy "stranger" {    permission java.io.FilePermission "question.txt", "read";};grant codeBase "file:${com.artima.ijvm.cdrom.home}/security/ex2/*" {permission java.io.FilePermission "question.txt", "read";permission java.io.FilePermission "answer.txt", "read";};

JAAS extends into:

That architecture, introduced in the Java 2 platform, is code-centric. That is, the permissions are granted based on code characteristics: where the code is coming from and whether it is digitally signed and if so by whom. We saw an example of this in the jaasacn.policy file used in the JAAS Authentication tutorial. That file contains the following:

grant codebase "file:./JaasAcn.jar" {   permission javax.security.auth.AuthPermission                     "createLoginContext.JaasSample";};

This grants the code in the JaasAcn.jar file, located in the current directory, the specified permission. (No signer is specified, so it doesn't matter whether the code is signed or not.)

JAAS authorization augments the existing code-centric access controls with new user-centric access controls. Permissions can be granted based not just on what code is running but also on who is running it.

grant <signer(s) field>, <codeBase URL>   <Principal field(s)> {    permission perm_class_name "target_name", "action";    ....    permission perm_class_name "target_name", "action";  };

Principal Principal_class "principal_name"