- Applets rarely require elevated privileges. Sign only those applets that require elevated privileges; other applets should not be signed. (See guideline ENV00-J. Do not sign code that performs only unprivileged operations.) For applications, the security policy that defines the set of permissions should be as restrictive as possible. The default security policy file grants permissions sparingly, however, the flexible security model allows the user to grant additional permissions to applications by defining a custom security policy. Several guidelines deal with granting or limiting permissions:
- There are several ways of satisfying the second goal of privilege separation to enhance security. Applets or applications that need to be signed can coexist with unsigned classes in the same package (or
JARfile). It is recommended that all privileged code be packaged together. (See guideline ENV01-J. Place all privileged code in a single package and seal the package for more information.) Furthermore, it is possible to grant privileges to code on the basis of the code base and/or its signer using a security policy.
- The third goal can be realized using the
AccessControllermechanism. This mechanism allows only certain parts of code to acquire elevated privileges. When a class needs to assert its privileges, it executes the privileged code in a
AccessControllermechanism works in conjunction with the security policy in effect. Because users may be unaware of the details of the security model and incapable of correctly configuring security policies tailored to their requirements, privileged code present within the
doPrivilegedblocks must be kept to a minimum to avoid security vulnerabilities.
- The fourth goal can be achieved using a security manager to control the functions the trusted Java API can perform. (See guideline ENV02-J. Create a secure sandbox using a Security Manager.) When untrusted code should be disallowed from accessing system classes, it should be granted specific permissions to prevent it from accessing trusted classes in the specified packages. The
accessClassInPackagepermission provides the required functionality. (See guideline SEC12-J. Do not grant untrusted code access to classes in inaccessible packages.) Doing so does not limit what system classes can do; however, it restricts the range of system packages that can be used from less-privileged code.