| Wiki Markup |
|---|
The default {{SecurityManager}} checks whether the caller of a particular method has sufficient permissions to proceed with an action. An action is a level of access,; for instance, the actions for {{java.io.FilePermission}} are "read", "write", "execute", and "delete" \[[Sun 2006|AA. Bibliography#Sun 06]\]. The "Permission Descriptions and Risks" guide \[[Permissions 2008|AA. Bibliography#Permissions 08]\] enumerates the default permissions and the risks associated with granting these permissions to Java code. |
Sometimes, stronger restrictions than those provided by the default security manager are necessary. Custom permissions prove to be more suitable for privilege separation in such cases. Failure to provide custom permissions when no corresponding default permissions exist , can lead to privilege escalation vulnerabilities wherein where untrusted callers can execute restricted operations or actions.
...
This noncompliant code example contains a privileged block that is used to perform two sensitive operations, loading a library and setting the default exception handler. When used, the default security manager does not permit the loading of the library unless the RuntimePermission loadLibrary.awt is granted in the policy file. However, the security manager does not automatically guard a caller from performing the second sensitive operation of setting the default exception handler. This is because the permission for this operation is not non-default and, consequently, unavailable. This security weakness can be exploited, for example, by programming and installing an exception handler that reveals information that a legitimate handler would filter out.
...
By default, permissions cannot be defined to support actions using BasicPermission, but the actions can be freely implemented in the subclass, if required. BasicPermission is abstract, even though it contains no abstract methods; it defines all the methods that it extends from the Permission class. The custom defined subclass of the BasicPermission class has to define two constructors to call the most appropriate (one- or two-argument) superclass constructor (the superclass lacks a default constructor). The two-argument constructor also accepts an action even though a basic permission does not use it. This is required for constructing permission objects from the policy file. Note that the custom defined subclass of the BasicPermission class is declared to be final in accordance with guideline SEC07-J. Classes that derive from a sensitive class or implement a sensitive interface should be declared to be final.
...
Running Java code without defining custom permissions where default ones permissions are inapplicable can leave an application open to privilege escalation vulnerabilities.
...
Search for vulnerabilities resulting from the violation of this guideline on the CERT website.
Related Guidelines
MITRE CWE: CWE-732, "Incorrect Permission Assignment for Critical Resource"
Bibliography
| Wiki Markup |
|---|
\[[API 2006|AA. Bibliography#API 06]\] [Class SecurityManager|http://java.sun.com/javase/6/docs/api/java/lang/SecurityManager.html] \[[Oaks 2001|AA. Bibliography#Oaks 01]\] Chapter 5: The Access Controller, "Permissions" \[[Policy 2002|AA. Bibliography#Policy 02]\] \[[Sun 2006|AA. Bibliography#Sun 06]\] [Permission Descriptions and Risks|http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html] \[[MITRE 2007|AA. Bibliography#MITRE 07]\] [CWE-732|http://cwe.mitre.org/data/definitions/732.html], "Incorrect Permission Assignment for Critical Resource" |
...
SEC09-J. Do not base security checks on untrusted sources 02. Platform Security (SEC) SEC11-J. Call the superclass's getPermissions method when writing a custom class loader