Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction

Wiki Markup
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 :

  • Wiki Markup
    \[1\] We want to grant each applet or application the minimum privileges it needs.
  • Wiki Markup
    \[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.
  • Wiki Markup
    \[3\] We want a class's privileges to be "turned off" except for brief periods of time.
  • Wiki Markup
    \[4\] We even want to reduce the privileges of some of the built-in system classes.

Wiki Markup
\[Our numbering.\]

The ways in which these goals can be achieved are discussed below.

  1. Applets rarely require elevated privileges. Sign only those applets that require elevated privileges; other applets should not be signed. (See guideline ENV00-J. Do not sign code that performs only unprivileged operations.) For applications, 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. Several guidelines deal with granting or limiting permissions:
  2. There are several ways of satisfying the second goal of privilege separation to enhance security. Applets or applications that need 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.
  3. The third goal can be realized using the 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.
  4. The fourth goal can be achieved using a security manager 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.

Guidelines

SEC00-J. Avoid granting excess privileges

SEC01-J. Minimize the accessibility of classes and their members

SEC02-J. Guard doPrivileged blocks against untrusted invocations

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

SEC05-J. Do not expose standard APIs that use the immediate caller's class loader instance to untrusted code

SEC06-J. Do not use APIs that perform access checks against the immediate caller

SEC07-J. Classes that derive from a sensitive class or implement a sensitive interface should be declared to be final

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

SEC19-J. Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar

SEC20-J. Do not expect java.lang.reflect.method.invoke() to behave as the immediate caller

Risk Assessment Summary

...

Rules

Content by Label
showLabelsfalse
max99
spacescom.atlassian.confluence.content.render.xhtml.model.resource.identifiers.SpaceResourceIdentifier@3bbaf8c
sorttitle
showSpacefalse
labels+sec, +rule, -void
cqllabel = "sec" and label = "rule" and label != "void" and space = currentSpace()

Risk Assessment Summary

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SEC00-J high Medium probable Likely high High

P6

L2

SEC01-J medium High likely Likely medium Low

P12 P27

L1

SEC02-J medium High likely Probable high Medium

P6 P12

L2 L1

SEC03-J high High likely Probable low Medium

P27 P12

L1

SEC04-J high High probable Probable medium Medium

P12

L1

SEC05-J high High probable Probable medium Medium

P12

L1

SEC06-J medium High likely Probable medium Medium

P12

L1

SEC06- J

high

probable

medium

P12

L1

SEC07-J medium High probable 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

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

ENV10-J. Do not disable bytecode verification      The CERT Oracle Secure Coding Standard for Java      SEC00-J. Avoid granting excess privileges

 

...

Image Added Image Added Image Added