Page History

...

Sealing a JAR file automatically enforces the requirement of keeping privileged code together. In addition, it is important to adhere to rule OBJ02-J. Minimize the accessibility of classes and their members.

Noncompliant Code Example (Privileged Code)

This noncompliant code example uses a doPrivileged block and calls a method defined in a class in a different, untrusted jar file.

...

This example comes close to violating SEC01-J. Do not allow tainted variables in privileged blocks but does not do so. It instead allows potentially tainted code in its doPrivileged() block, which is a similar issue.

Noncompliant Code Example (Security-Sensitive Code)

This noncompliant code example improves upon the previous example by moving the use of the RetValue class outside the doPrivileged() block.

...

Although the RetValue class is used only outside the doPrivileged() block, the behavior of RetValue.getValue() certainly affects the behavior of security-sensitive code; that is, the code that operates on the file opened within the doPrivileged() block. Consequently, an attacker can still exploit the security-sensitive code with a malicious implementation of RetValue.

Compliant Solution

This compliant solution combines all security-sensitive code into the same package and the same jar file. It also reduces the accessibility of the getValue() method to package-private. Sealing the package is necessary to prevent attackers from inserting any rogue classes.

...

Name: trusted/ // package name
Sealed: true  // sealed attribute

Exception

ENV01-EX0: Independent groups of privileged code and associated security-sensitive code (a "group" hereafter) may be placed in separate sealed packages and even in separate jar files, subject to certain enabling conditions. These conditions are:

• The code in any one of these independent groups must lack any dynamic or static dependency on any of the code in any of the other groups. This means that code from one such group cannot invoke code from any of the others, whether directly or transitively.
• All code from any single group is contained within one or more sealed packages.
• All code from any single group is contained within a single signed jar file.

Risk Assessment

Failure to place all privileged code together in one package and seal the package can lead to mix and match attacks.

Automated Detection

Detecting code that should be considered privileged or sensitive requires programmer assistance. Given identified privileged code as a starting point, automated tools could compute the closure of all code that can be invoked from that point. Such a tool could plausibly determine whether all code in that closure exists within a single package. A further check of whether the package is sealed appears feasible.

Related Guidelines

Bibliography

...