Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Red Hat Enterprise Linux 9 Essentials Book now available.

Purchase a copy of Red Hat Enterprise Linux 9 (RHEL 9) Essentials

Red Hat Enterprise Linux 9 Essentials Print and eBook (PDF) editions contain 34 chapters and 298 pages

Preview Book

41.5. Security Updates

As security vulnerabilities are discovered, the affected software must be updated in order to limit any potential security risks. If the software is part of a package within a Red Hat Enterprise Linux distribution that is currently supported, Red Hat, Inc. is committed to releasing updated packages that fix the vulnerability as soon as possible. Often, announcements about a given security exploit are accompanied with a patch (or source code that fixes the problem). This patch is then applied to the Red Hat Enterprise Linux package, tested by the Red Hat quality assurance team, and released as an errata update. However, if an announcement does not include a patch, a Red Hat developer works with the maintainer of the software to fix the problem. Once the problem is fixed, the package is tested and released as an errata update.

If an errata update is released for software used on your system, it is highly recommended that you update the effected packages as soon as possible to minimize the amount of time the system is potentially vulnerable.

41.5.1. Updating Packages

When updating software on a system, it is important to download the update from a trusted source. An attacker can easily rebuild a package with the same version number as the one that is supposed to fix the problem but with a different security exploit and release it on the Internet. If this happens, using security measures such as verifying files against the original RPM does not detect the exploit. Thus, it is very important to only download RPMs from trusted sources, such as from Red Hat, Inc. and check the signature of the package to verify its integrity.

Red Hat offers two ways to find information on errata updates:

  1. Listed and available for download on Red Hat Network

  2. Listed and unlinked on the Red Hat Errata website

Note

Beginning with the Red Hat Enterprise Linux product line, updated packages can be downloaded only from Red Hat Network. Although the Red Hat Errata website contains updated information, it does not contain the actual packages for download.

41.5.1.1. Using Red Hat Network

Red Hat Network allows the majority of the update process to be automated. It determines which RPM packages are necessary for the system, downloads them from a secure repository, verifies the RPM signature to make sure they have not been tampered with, and updates them. The package install can occur immediately or can be scheduled during a certain time period.

Red Hat Network requires a System Profile for each machine to be updated. The System Profile contains hardware and software information about the system. This information is kept confidential and is not given to anyone else. It is only used to determine which errata updates are applicable to each system, and, without it, Red Hat Network can not determine whether a given system needs updates. When a security errata (or any type of errata) is released, Red Hat Network sends an email with a description of the errata as well as a list of systems which are affected. To apply the update, use the Red Hat Update Agent or schedule the package to be updated through the website https://rhn.redhat.com.

Tip

Red Hat Enterprise Linux includes the Red Hat Network Alert Notification Tool, a convenient panel icon that displays visible alerts when there is an update for a registered Red Hat Enterprise Linux system. Refer to the following URL for more information about the applet: https://rhn.redhat.com/help/basic/applet.html

Important

Before installing any security errata, be sure to read any special instructions contained in the errata report and execute them accordingly. Refer to Section 41.5.1.5, “Applying the Changes” for general instructions about applying the changes made by an errata update.

41.5.1.2. Using the Red Hat Errata Website

When security errata reports are released, they are published on the Red Hat Errata website available at https://www.redhat.com/security/. From this page, select the product and version for your system, and then select security at the top of the page to display only Red Hat Enterprise Linux Security Advisories. If the synopsis of one of the advisories describes a package used on your system, click on the synopsis for more details.

The details page describes the security exploit and any special instructions that must be performed in addition to updating the package to fix the security hole.

To download the updated package(s), click on the link to login to Red Hat Network, click the package name(s) and save to the hard drive. It is highly recommended that you create a new directory, such as /tmp/updates, and save all the downloaded packages to it.

41.5.1.3. Verifying Signed Packages

All Red Hat Enterprise Linux packages are signed with the Red Hat, Inc. GPG key. GPG stands for GNU Privacy Guard, or GnuPG, a free software package used for ensuring the authenticity of distributed files. For example, a private key (secret key) held by Red Hat locks the package while the public key unlocks and verifies the package. If the public key distributed by Red Hat does not match the private key during RPM verification, the package may have been altered and therefore cannot be trusted.

The RPM utility within Red Hat Enterprise Linux automatically tries to verify the GPG signature of an RPM package before installing it. If the Red Hat GPG key is not installed, install it from a secure, static location, such as an Red Hat Enterprise Linux installation CD-ROM.

Assuming the CD-ROM is mounted in /mnt/cdrom, use the following command to import it into the keyring (a database of trusted keys on the system):

rpm --import /mnt/cdrom/RPM-GPG-KEY

To display a list of all keys installed for RPM verification, execute the following command:

rpm -qa gpg-pubkey*

For the Red Hat key, the output includes the following:

gpg-pubkey-db42a60e-37ea5438

To display details about a specific key, use the rpm -qi command followed by the output from the previous command, as in this example:

rpm -qi gpg-pubkey-db42a60e-37ea5438

It is extremely important to verify the signature of the RPM files before installing them to ensure that they have not been altered from the Red Hat, Inc. release of the packages. To verify all the downloaded packages at once, issue the following command:

rpm -K /tmp/updates/*.rpm

For each package, if the GPG key verifies successfully, the command returns gpg OK. If it doesn't, make sure you are using the correct Red Hat public key, as well as verifying the source of the content. Packages that do not pass GPG verifications should not be installed, as they may have been altered by a third party.

After verifying the GPG key and downloading all the packages associated with the errata report, install the packages as root at a shell prompt.

41.5.1.4. Installing Signed Packages

Installation for most packages can be done safely (except kernel packages) by issuing the following command:

rpm -Uvh /tmp/updates/*.rpm

For kernel packages use the following command:

rpm -ivh /tmp/updates/<kernel-package>

Replace <kernel-package> in the previous example with the name of the kernel RPM.

Once the machine has been safely rebooted using the new kernel, the old kernel may be removed using the following command:

rpm -e <old-kernel-package>

Replace <old-kernel-package> in the previous example with the name of the older kernel RPM.

Note

It is not a requirement that the old kernel be removed. The default boot loader, GRUB, allows for multiple kernels to be installed, then chosen from a menu at boot time.

Important

Before installing any security errata, be sure to read any special instructions contained in the errata report and execute them accordingly. Refer to Section 41.5.1.5, “Applying the Changes” for general instructions about applying the changes made by an errata update.

41.5.1.5. Applying the Changes

After downloading and installing security errata via Red Hat Network or the Red Hat errata website, it is important to halt usage of the older software and begin using the new software. How this is done depends on the type of software that has been updated. The following list itemizes the general categories of software and provides instructions for using the updated versions after a package upgrade.

Note

In general, rebooting the system is the surest way to ensure that the latest version of a software package is used; however, this option is not always available to the system administrator.

Applications

User-space applications are any programs that can be initiated by a system user. Typically, such applications are used only when a user, script, or automated task utility launches them and they do not persist for long periods of time.

Once such a user-space application is updated, halt any instances of the application on the system and launch the program again to use the updated version.

Kernel

The kernel is the core software component for the Red Hat Enterprise Linux operating system. It manages access to memory, the processor, and peripherals as well as schedules all tasks.

Because of its central role, the kernel cannot be restarted without also stopping the computer. Therefore, an updated version of the kernel cannot be used until the system is rebooted.

Shared Libraries

Shared libraries are units of code, such as glibc, which are used by a number of applications and services. Applications utilizing a shared library typically load the shared code when the application is initialized, so any applications using the updated library must be halted and relaunched.

To determine which running applications link against a particular library, use the lsof command as in the following example:

lsof /usr/lib/libwrap.so*

This command returns a list of all the running programs which use TCP wrappers for host access control. Therefore, any program listed must be halted and relaunched if the tcp_wrappers package is updated.

SysV Services

SysV services are persistent server programs launched during the boot process. Examples of SysV services include sshd, vsftpd, and xinetd.

Because these programs usually persist in memory as long as the machine is booted, each updated SysV service must be halted and relaunched after the package is upgraded. This can be done using the Services Configuration Tool or by logging into a root shell prompt and issuing the /sbin/service command as in the following example:

/sbin/service <service-name> restart

In the previous example, replace <service-name> with the name of the service, such as sshd.

Refer to Chapter 14, Network Configuration for more information on the Services Configuration Tool.

xinetd Services

Services controlled by the xinetd super service only run when a there is an active connection. Examples of services controlled by xinetd include Telnet, IMAP, and POP3.

Because new instances of these services are launched by xinetd each time a new request is received, connections that occur after an upgrade are handled by the updated software. However, if there are active connections at the time the xinetd controlled service is upgraded, they are serviced by the older version of the software.

To kill off older instances of a particular xinetd controlled service, upgrade the package for the service then halt all processes currently running. To determine if the process is running, use the ps command and then use the kill or killall command to halt current instances of the service.

For example, if security errata imap packages are released, upgrade the packages, then type the following command as root into a shell prompt:

ps -aux | grep imap

This command returns all active IMAP sessions. Individual sessions can then be terminated by issuing the following command:

kill <PID>

If this fails to terminate the session, use the following command instead:

kill -9 <PID>

In the previous examples, replace <PID> with the process identification number (found in the second column of the ps command) for an IMAP session.

To kill all active IMAP sessions, issue the following command:

killall imapd

 
 
  Published under the terms of the Open Publication License Design by Interspire