Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  1. 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:
  2. 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 JAR file). 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.
  3. The third goal can be realized using the AccessController mechanism. 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 doPrivileged block. The AccessController mechanism 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 doPrivileged blocks must be kept to a minimum to avoid security vulnerabilities.
  4. 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 accessClassInPackage permission 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.


SEC00-J. Follow the principle of least privilegeAvoid granting excess privileges

SEC01-J. Minimize the accessibility of classes and their members


ENV10-J. Do not disable bytecode verification      The CERT Oracle Secure Coding Standard for Java      SEC00-J. Follow the principle of least privilegeAvoid granting excess privileges