Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 180 Next »

Guidelines

Introduction

According to the principle of least privilege, every program and every user of the system should operate using the least set of privileges necessary to complete the particular task [[Saltzer 1974], [Saltzer 1975]]. The Build Security In website [[DHS 2006]] provides additional definitions of this principle. Executing with minimal privileges mitigates against exploitation in case a vulnerability is discovered in the code. These principles can be applied in various ways to Java language programming.

Java code should be run with the minimum required privileges. Sign only the code that requires elevated privileges; other code should not be signed. (See rule ENV00-J. Do not sign code that performs only unprivileged operations.) 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 rules that enforce this principle include:

Code that 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 rule 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.

Privileged operations should be limited to the smallest possible code blocks that require such privileges. The Java AccessController 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.

A security manager is an object that defines a security policy for Java code. This policy specifies actions that are unsafe or sensitive. Any actions not allowed by the security policy cause a SecurityException to be thrown. 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 rule 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 rule 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.

Risk Assessment Summary

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

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

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

SEC11-J

high

probable

low

P18

L1

SEC12-J

high

likely

high

P9

L2

SEC13-J

high

likely

high

P9

L2

SEC18-J

medium

probable

high

P4

L3

SEC19-J

high

probable

medium

P12

L1

SEC21-J

high

probable

high

P6

L2


FIO16-J. Perform proper cleanup at program termination      The CERT Oracle Secure Coding Standard for Java      OBJ15-J. Minimize the accessibility of classes and their members

  • No labels