Versions Compared

Key

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

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. In fact, trusted 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.

Execution of untrusted code causes loss of privileges. When trusted code calls some untrusted code that attempts to perform some action requiring permissions withheld by the security policy, the action is not allowed. However, privileged code may use a class that exists in an untrusted container and performs only unprivileged operations. If the attacker were to replace this class with a malicious implementation, the trusted code would retrieve incorrect results.

...

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 that exists 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 one example by moving the use of the RetValue class outside the doPrivileged() block.

...

To seal a package, use the sealed attribute in the jar file's manifest file header, as shown belowfollows.

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

...

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="232289fd219c87e2-164cb2ef-4923495d-82698df4-13db2a78828154da1bafbfe9"><ac:plain-text-body><![CDATA[

[[API 2006

AA. Bibliography#API 06]]

 

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="a8d94c4481323e1a-b3f94514-4367440a-a26d97ac-eaaafd3a8971b20fb105e539"><ac:plain-text-body><![CDATA[

[[McGraw 1999

AA. Bibliography#Ware 99]]

Rule 7: If You Must Sign Your Code, Put It All in One Archive File (sic)

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="5cb9646070a95532-533fcbdc-453f4c26-96abb601-650e566c4dac05099bb69ffa"><ac:plain-text-body><![CDATA[

[[Ware 2008

AA. Bibliography#Ware 08]]

 

]]></ac:plain-text-body></ac:structured-macro>

...