...
Java code should be run with the minimum required privileges. Applets rarely require elevated privileges. Sign only those applets the code that require requires elevated privileges; other applets code should not be signed. (See guideline ENV00-J. Do not sign code that performs only unprivileged operations.) For applications, the 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. Specific guidelines that enforce this principle include:
- SEC00-J. Avoid granting excess privileges
- SEC21-J. Remove superfluous code from privileged blocks
- ENV00-J. Do not sign code that performs only unprivileged operations
- ENV03-J. Never grant AllPermission to untrusted code
- ENV04-J. Do not grant ReflectPermission with target suppressAccessChecks
- ENV05-J. Do not grant RuntimePermission with target createClassLoader
Applets or applications Code that need needs 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.
...
A security manager is an object that defines a security policy for an applicationJava code. This policy specifies actions that are unsafe or sensitive. Any actions not allowed by the security policy cause a SecurityException to be thrown. An application Code can also query its security manager to discover which actions are allowed. The security manager can also be used 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.
...