According to the principle of least privilege, code should not be granted more privileges than those required for performing the particular task. This means that sections of code that require elevated privileges should be kept to a minimum. McGraw and Felten \[[McGraw 2000|AA. Bibliography#McGraw 00]\] enlist various goals of the principle of least privilege in the context of the Java programming language : |
\[1\] We want to grant each applet or application the minimum privileges it needs.
\[2\] Rather than assigning a given applet's \[or application's\] entire collection of privileges to all of its classes, we want each class to get just what it needs.
\[3\] We want a class's privileges to be "turned off" except for brief periods of time.
\[4\] We even want to reduce the privileges of some of the built-in system classes.
\[Our numbering.\] |
The ways in which these goals can be achieved are discussed below.
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.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.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. Avoid granting excess privileges
SEC01-J. Minimize the accessibility of classes and their members
SEC02-J. Guard doPrivileged blocks against untrusted invocation and leakage of sensitive data
SEC03-J. Do not allow tainted variables in doPrivileged blocks
SEC04-J. Do not expose standard APIs that may bypass Security Manager checks to untrusted code
SEC06-J. Do not use APIs that perform access checks against the immediate caller
SEC08-J. Enforce security checks in code that performs sensitive operations
SEC09-J. Do not base security checks on untrusted sources
SEC10-J. Define custom security permissions for fine grained security
SEC11-J. Call the superclass's getPermissions method when writing a custom class loader
SEC12-J. Do not grant untrusted code access to classes in inaccessible packages
SEC13-J. Do not allow unauthorized construction of classes in inaccessible packages
SEC14-J. Provide sensitive mutable classes with unmodifiable wrappers
SEC15-J. Prefer using SSLSockets over Sockets for secure data exchange
SEC16-J. Sign and seal sensitive objects before transit
SEC17-J. Create and sign a SignedObject before creating a SealedObject
SEC18-J. Define wrappers around native methods
SEC20-J. Do not expect java.lang.reflect.method.invoke() to behave as the immediate caller
SEC21-J. Remove superfluous code from privileged blocks
Guideline |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
SEC00- J |
high |
probable |
high |
P6 |
L2 |
SEC01- J |
medium |
likely |
medium |
P12 |
L1 |
SEC02- J |
medium |
likely |
high |
P6 |
L2 |
SEC03- J |
high |
likely |
low |
P27 |
L1 |
SEC04- J |
high |
probable |
medium |
P12 |
L1 |
SEC05- J |
high |
probable |
medium |
P12 |
L1 |
SEC06- J |
medium |
likely |
medium |
P12 |
L1 |
SEC06- J |
high |
probable |
medium |
P12 |
L1 |
SEC07- J |
medium |
probable |
low |
P12 |
L1 |
SEC08- J |
high |
probable |
medium |
P12 |
L1 |
SEC09- J |
high |
probable |
medium |
P12 |
L1 |
SEC10- J |
medium |
probable |
high |
P4 |
L3 |
SEC11- J |
high |
probable |
low |
P18 |
L1 |
SEC12- J |
high |
likely |
high |
P9 |
L2 |
SEC13- J |
high |
likely |
high |
P9 |
L2 |
SEC14- J |
medium |
probable |
high |
P4 |
L3 |
SEC15- J |
medium |
likely |
high |
P6 |
L2 |
SEC16- J |
medium |
probable |
high |
P4 |
L3 |
SEC17- J |
medium |
likely |
low |
P18 |
L1 |
SEC18- J |
medium |
probable |
high |
P4 |
L3 |
SEC19- J |
high |
probable |
medium |
P12 |
L1 |
SEC21- J |
high |
probable |
high |
P6 |
L2 |
ENV10-J. Do not disable bytecode verification The CERT Oracle Secure Coding Standard for Java SEC00-J. Avoid granting excess privileges