Code signing was introduced in Java 2 to provide a mechanism for granting elevated privileges to code depending on the security policy in effect. For example, signed Java applets that need to read system properties from a user's machine can escape the default sandbox restrictions by being signed. Then the user can be . 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 privileges.
...
| 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. 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 Any code that is incomprehensible or unaudited must not be signed ([SEC32-J. Create and sign a SignedObject before creating a SealedObject]). |
...