Managing Signed Patches (Overview)

This chapter provides overview information for using signed patches with Solaris systems. This chapter contains the following overview information:

• Overview of Signed Patches

• Sun Certificates That Verify Signed Patches

• Solaris Patch Management Tools for Signed Patches

For instructions on using Solaris patch management tools to manage signed patches, see Chapter 2, Managing Signed Patches by Using Solaris Patch Management Tools (Tasks). For instructions on using signed patches without Solaris patch management tools, see Appendix A, Managing Signed Patches Without Solaris Patch Management Tools (Tasks).

Overview of Signed Patches

Solaris 2.6, Solaris 7, Solaris 8, and Solaris 9 patches provided by Sun Microsystems include a digital signature. Patches with this digital signature are called signed patches.

A signed patch offers greater security than an unsigned patch. The digital signature on the patch can be verified before the patch is applied to your system. A valid digital signature ensures that the signed patch that you apply has not been modified since the signature was applied.

Signed patches are stored in Java Archive (JAR) format files. Both signed patches and unsigned patches are available from the SunSolve Online^SM Web site at http://sunsolve.sun.com. Follow the Patchfinder link and specify the patches that you want to download. You can download signed or unsigned patches.

Signed patches can be managed with or without Solaris patch management tools. For overview information about patch management tools, see Solaris Patch Management Tools for Signed Patches. For information about managing signed patches without using Solaris patch management tools, see Appendix A, Managing Signed Patches Without Solaris Patch Management Tools (Tasks).

Sun Certificates That Verify Signed Patches

Digital certificates, issued and authenticated by Sun Microsystems, are used to verify that the downloaded patch archive with the digital signature has not been compromised.

Sun PKI Registration Authorities

The Sun™ Public Key Infrastructure (Sun PKI) architecture is designed with one top-level certificate and a subordinate certificate authority (CA). The top-level certificate is called the Root CA. The subordinate CA is called the Sun Microsystems, Inc. CA (Class B) certificate. An additional certificate, the patch signing certificate, is issued by Sun Enterprise™ Services and verifies the digital signatures on signed patches.

Sun certificates are issued by Baltimore Technologies, who recently bought GTE CyberTrust.

The Sun Root CA and the Sun Class B CA are available from http://www.sun.com/pki/ca. The patch signing certificate is included in the SUNWppro package.

These three certificates provide a certificate chain of trust in the patch verification process. The Sun Root CA certifies the Class B CA, and the Class B CA certifies the patch signing certificate. And ultimately, the GTE CyberTrust CA certifies the Sun Root CA.

A certification authority certifies the relationship between public keys and the owner of the public keys. The public keys are used to validate the digital signature that is found in the patch JAR file.

The Sun CA process means that the following statements are true:

• Sun has issued and authenticated the digital certificates.

• The public keys in the certificates are paired with a private key that is held by Sun.

• These certificates can be used for business purposes only. The certificates can be revoked or suspended if the certificate user violates Sun's certificate policy.

For information about Sun's certificate policy, see http://www.sun.com/pki/cps.html.

Revoked Sun Certificates

If the Sun Root or Class B certificates are stolen or lost, the certificates are revoked. A revoked certificate list is posted at http://www.sun.com/pki/ca/pkismica.crl.html.

View this site occasionally to verify that your imported certificates are still valid. If your imported certificates are revoked, remove them from your keystore and import replacement certificates.

If the patch signing certificate is revoked, the existing signed patches on the SunSolve Online site will be replaced by patches that have a new digital signature.

Solaris Patch Management Tools for Signed Patches

You use the smpatch command with Solaris Patch Manager Base 1.0.1 to manage signed patches on systems that run the Solaris 2.6, Solaris 7, and Solaris 8 releases. You use the smpatch command with PatchPro 2.2 to manage signed patches on systems that run the Solaris 9 release.

Both Solaris patch management tools for signed patches provide the following capabilities:

• Analyzing patch requirements and downloading signed patches for the local system only.

• Applying one or more signed patches in JAR format. They also authenticate the patch or patches to be applied.

• Solaris 9 GUI only - Removing one or more patches. Patch dependencies are checked beforehand.

• Enabling you to set up a default policy for applying patches of various types, such as rebootafter and standard.

Note - You can still use the patchadd command to apply unsigned patches to systems that run the Solaris 2.6, Solaris 7, Solaris 8, and Solaris 9 releases.

You cannot use Patch Manager Base 1.0.1 to apply unsigned patches to Solaris 2.6, Solaris 7, or Solaris 8 systems. However, you can use smpatch add to apply unsigned patches to Solaris 9 systems.

Manual and Automatic Application of Patches

Patches are classified as standard patches or nonstandard patches. The Solaris patch management tools can apply patches in two modes: automatic mode and manual mode. In automatic mode, only standard patches can be applied on a regularly scheduled basis. In manual mode, all standard patches and most nonstandard patches can be applied from the command line.

A standard patch is one that is safe to apply and can be applied while the system is in multiuser mode. The effects of the patch are visible as soon as it is applied unless the application being patched is running while the patch is applied. In this case, the effects of the patch are visible after the affected application is restarted. A standard patch is associated with the standard property and can be applied in automatic mode.

A nonstandard patch has one of the following characteristics:

• A patch that is associated with the interactive property.

• A patch that is associated with the rebootafter, rebootimmediate, reconfigafter, reconfigimmediate, or singleuser properties. This nonstandard patch can be applied in manual mode.

• A patch that cannot be applied by running the patch management tools, but must be applied by following the instructions in the patch's README file.

Two options are available for applying patches in automatic mode:

• Standard patches only - Only standard patches are downloaded to the patch directory and applied. A standard patch is one that does not require any special actions on the part of the user. A standard patch also does not require a reboot for the patch to take effect.

  Specify this policy by using the pprosetup -p standard command.

• No patches - No patches are downloaded to the patch directory or applied. This option is the default.

  Specify this policy by using the pprosetup -p none command.

Most nonstandard patches can only be applied in manual mode. You can specify the patch policy for manual mode by using this command:

# pprosetup -i patch-property-list

patch-property-list is one or more of the following patch properties: interactive, rebootafter, rebootimmediate, reconfigafter, reconfigimmediate, singleuser, and standard. For descriptions of the patch properties, see the pprosetup(1M) man page.

A number of patches cannot be applied by PatchPro 2.2 or by Patch Manager Base 1.0.1 under any circumstances. For instance, nonconforming patches cannot be applied by using the smpatch, pprosvc, or patchadd command. Nonconforming patches must be extracted manually and applied by following the instructions in the patch's README file.