...
The SecurityManager.checkSecurityAccess()
method determines whether or not the action controlled by the particular permission is allowed or not.
Noncompliant Code Example (check*()
)
...
Code Block | ||
---|---|---|
| ||
SecurityManager sm = System.getSecurityManager(); if (sm != null) { // checkCheck whether file may be read sm.checkRead("/local/schema.dtd"); } |
Compliant Solution (checkPermission()
)
Java SE 1.2 added two methods — methods—checkPermission(Permission perm)
and checkPermission(Permission perm, Object context)
— to —to the SecurityManager
class. The motivations for this change included
- eliminating Eliminating the need to hard - code names of checks in method names.
- encapsulating Encapsulating the complicated algorithms and code for examining the Java runtime in a single
checkPermission()
method. - supporting Supporting introduction of additional permissions by subclassing the
Permission
class.
The single-argument checkPermission()
method uses the context of the currently executing thread environment to perform the checks. If the context has the permissions defined in the local policy file, the check succeeds; otherwise, a SecurityException
is thrown.
This compliant solution shows the single-argument checkPermission()
method that checks to see whether the files in the local
directory that have the dtd
extension can be read. DTDPermission
is a custom permission that enforces this level of access. Even if the java.io.FilePermission
is granted to the application with the action read
, DTD
files are subject to additional access control.
Code Block | ||
---|---|---|
| ||
SecurityManager sm = System.getSecurityManager(); if (sm != null) { //check Check whether file canmay be read or not DTDPermission perm = new DTDPermission("/local/", "readDTD"); sm.checkPermission(perm); } |
...
Occasionally, the security check code exists in one context (such as a worker thread), while whereas the check must be conducted on a different context, such as on another thread. The two-argument checkPermission()
method is used in this case. It accepts an AccessControlContext
instance as the context
argument. The effective permissions are those of the context
argument only rather than the intersection of the permissions of the two contexts.
Both the single- and double-argument checkPermission()
methods defer to the single-argument java.security.AccessController.checkPermission(Permission perm)
method. When invoked directly, this method operates only on the current execution context and, as a result, does not supersede the security manager's two-argument version.
A cleaner approach to making a security check from a different context is to take a snapshot of the execution context in which the check must be performed, using the java.security.AccessController.getContext()
method that returns an AccessControlContext
object. The AccessControlContext
class itself defines a checkPermission()
method that encapsulates a context instead of accepting the current executing context as an argument. This approach allows the check to be performed at a later time, as shown in the following example.
Code Block | ||
---|---|---|
| ||
// Take the snapshot of the required context, store in acc, and pass it to another context
AccessControlContext acc = AccessController.getContext();
// Accept acc in another context and invoke checkPermission() on it
acc.checkPermission(perm);
|
...
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
SEC04-J | highHigh | probableProbable | mediumMedium | P12 | L1 |
Automated Detection
Identifying sensitive operations requires assistance from the programmer; fully automated identification of sensitive operations is beyond the current state of the art.
...
The java.security
package exists on Android for compatibility purposes only, and it should not be used.
Bibliography
...