Page History

In Java SE 6 and Java SE 7, privileged code either uses the AccessController mechanism or must be signed by an owner (or provider) who is trusted by the user. Attackers could link privileged code with malicious code if the privileged code directly or indirectly invokes code from another package. Trusted jar files often contain code that lacks direct privileges , but that depends on privileged code; such code is known as security-sensitive code. If an attacker can link security-sensitive code with malicious code, they can indirectly cause incorrect behavior with sensitive data. This is called a mix and match attack.

...

According to the Java API \[[JarSpec 2008|AA. Bibliography#JarSpec 08]\], {{JAR}} file specification,

A package sealed within a JAR specifies that all classes defined in that package must originate from the same JAR. Otherwise, a SecurityException is thrown.

...

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.

...

• 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 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.

...

Related Guidelines

...

...