Code signing was introduced in Java to provide a mechanism for granting elevated privileges to code depending on irrespective of 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 when signed. When a signed applet is run, the user is prompted with a security dialog, 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 privilegesBoth these approaches place the control with the user who can choose to run the application either restrictively or with full permissions.
| Wiki Markup |
|---|
Signing code, however, has its own problems. According to Schneier \[[Schneier 00|AA. Java References#Schneier 00]\]: |
...
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 Because many users when prompted with the security dialog, choose the option of permanently trusting the organizations that they have full confidence inconsider trustworthy, they are not notified about potentially harmful content if an adversary offers in the future while downloading trusted but potentially vulnerable content signed by the trusted organization. An adversary may offer them the vulnerable software content 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. The dialog asks whether the signed code should be executed or not. Unfortunately, by default this setting overrides any future warning dialogs when if the user chooses to execute the code with the check box selected. An adversary may take advantage of this by supplying vulnerable code signed by the trusted organization. In this case, the code executes without the user's permission and may be freely exploited.
An organization that signs its code must not vouch for code acquired from a third party without carefully auditing it. The AccessController mechanism may be used wherein only the privileged code (doPrivileged() section) should be signed. The other While signing privileged code make sure it exists in the same package (ENV04-J. Place all privileged code in a single package and seal the package). Likewise, any code that is called from the privileged code must also exist in the same package. Non-privileged code can be left unsigned, restricting it to the sandbox. Any Additionally, any code that is incomprehensible or unaudited must not be signed (SEC32-J. Create and sign a SignedObject before creating a SealedObject).
...