The feature of code Code signing was introduced in Java 2 to provide an alternative a mechanism for granting elevated privileges to code depending on the security policy in effect. For example, Java applets that need to read system properties from a user's machine can escape the default sandbox restrictions by prompting being signed. Then the user can be prompted with a security dialog, about asking whether the party that signed the code is considered trustworthy. This element of trusting the signature allows applets to escape the default security sandbox restrictions. On the other hand, with applications that use a custom security policy, explicit permissions need to be granted to the particular codebase and optionally, the signer. This has the benefit of ensuring that only trusted signed code runs with the specified privileges.
...
Code signing is designed primarily to verify authenticity of origin and integrity of the code. It relies on the Certification Authority (CA) to duly confirm the identity of the principal signer. Naive users should not be expected to understand how certificates and the Public Key Infrastructure (PKI) work. All too often, they associate digital signatures with safety of code execution, and trust the code to cause them no harm.
In general, there is a misconception that signed code is safe to be executed. The problem manifests itself when a vulnerability is discovered in signed code. As many users choose the option of permanently trusting the organizations that they have full confidence in, they are not notified if an adversary offers them the vulnerable software with the intentions of exploiting it. Consider, for example, signed Java applets. Whenever a certificate is verified to be correct (as opposed to being self-signed or tampered), on widely used platforms the user is confronted with a security dialog that has the check box option "Always trust the content from the publisher" turned on. Unfortunately, this setting overrides any future warning dialogs about potentially vulnerable software versions from the respective organization.
| Wiki Markup |
|---|
In addition, McGraw and Felten \[[McGraw 00|AA. Java References#McGraw 00]\] stress that only privileged code should be signed. They further recommend that, since all development is not in-house, an organization that signs its code must not vouch for code acquired from a third party. Anything that is not comprehensible must not be signed (Also see the related guideline [SEC32-J. Create and sign a SignedObject before creating a SealedObject]). They suggest using the {{AccessController}} mechanism wherein only the privileged code ({{doPrivileged() section}}) ought to be signed. The other code can be left unsigned, restricting it to the sandbox. (Also see the related guideline [SEC32-J. Create and sign a SignedObject before creating a SealedObject]). |
It follows that unprivileged code is not required to be digitally signed and therefore should not be. This conviction adequately respects the guideline SEC00-J. Follow the principle of least privilege.
...
Signing unprivileged code violates the principle of least privilege as it can circumvent security restrictions defined by the security policies of applets and Java Network Launch Protocol (JNLP) applications, for example.
...