Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: wordsmithing

...

Consider, for example, signed Java applets. When a certificate is verified, on widely used platforms, the user is presented with a security dialog in which the option "Always trust the content from the publisher" is selected by default. The dialog primarily asks whether the signed code should be executed or not. Unfortunately, if the user confirms the dialog with the check box selected, the "Always trust..." setting overrides any future warning dialogs. An attacker can take advantage of this mechanism by supplying exploiting vulnerable code signed by the trusted organization. In this case, the code will execute with the user's implied permission and can be freely exploited.

An organization that signs its own code should not vouch for code acquired from a third party without carefully auditing the third-party code. When signing privileged code, ensure that all of the signed code is confined to a single package (as in rule ENV01-J. Place all privileged code in a single package and seal the package for more information), and also that any code invoked from the privileged code is also contained in that package. Non-privileged code should must be left unsigned, restricting it to the sandbox. Additionally, avoid signing any code that is incomprehensible or unaudited. (See rule void SEC17-J. Create and sign a SignedObject before creating a SealedObject. ) Signing unprivileged code is unnecessary; avoid doing so. See rule SEC00-J. Avoid granting excess privileges. For instance, unsigned applets and JNLP applications are granted the minimum set of privileges and are restricted to the sandbox. Finally, never sign any code that is incomprehensible or unaudited.

Exceptions

ENV00-EX1: An organization that has an internal PKI and uses code signing for internal development activities (such as facilitating code - check-in and tracking developer activity) may sign unprivileged code. This codebase should not be carried forward to the production environment. The keys used for internal signing must be distinct from those used to sign externally available code.

...