Is it possible to limit yum so that it lists or installs only security updates?
Environment
- Red Hat Enterprise Linux 8.x
- Red Hat Enterprise Linux 7.x
- Red Hat Enterprise Linux 6.x
- Red Hat Enterprise Linux 5.1 and later
- Red Hat Network Hosted
- Red Hat Satellite
Issue
- Is it possible to limit yum so that it lists or installs only security updates?
- How to update a system using yum and only apply security errata?
- How to patch the system only with security erratas ?
Resolution
- Install the yum-security plugin
It is now possible to limit yum to install only security updates (as opposed to bug fixes or enhancements) using Red Hat Enterprise Linux 5,6, and 7. To do so, simply install the yum-security plugin:
For Red Hat Enterprise Linux 7 and 8
The plugin is already a part of yum itself, no need to install anything.
For Red Hat Enterprise Linux 6
# yum install yum-plugin-security
For Red Hat Enterprise Linux 5
# yum install yum-security
Alternatively, download the yum-security package from the Red Hat Network (RHN) and manually install it on the system.
For Red Hat Enterprise Linux 6, 7 & 8
-
Using yum-security plugin
-
To list all available erratas without installing them, run:
# yum updateinfo list available
- To list all available security updates without installing them, run:
# yum updateinfo list security all
# yum updateinfo list sec
- To get a list of the currently installed security updates this command can be used:
# yum updateinfo list security installed
For Red Hat Enterprise Linux 5
-
Using yum-security plugin
-
To list all available erratas without installing them, run:
# yum list-sec
- To list all available security updates without installing them, run:
# yum list-security --security
For Red Hat Enterprise Linux 5, 6, 7 and 8
- To list all available security updates with verbose descriptions of the issues they apply to:
# yum updateinfo info security
- Run the following command to download and apply all available security updates from Red Hat Network hosted or Red Hat Network Satellite:
# yum -y update --security
NOTE: It will install the last version available of any package with at least one security errata thus can install non-security erratas if they provide a more updated version of the package. Updating using --security may still increase the minor release of the system in question if the dependencies being installed result in a newer minor release being installed.
- To only install the packages that have a security errata use
# yum update-minimal --security -y
yum-securityalso allows installing security updates based on the CVE reference of the issue. To install a security update using a CVE reference run:
# yum update --cve <CVE>
e.g.
# yum update --cve CVE-2008-0947
Viewing available advisories by severities:
# yum updateinfo list
This system is receiving updates from RHN Classic or RHN Satellite.
RHSA-2014:0159 Important/Sec. kernel-headers-2.6.32-431.5.1.el6.x86_64
RHSA-2014:0164 Moderate/Sec. mysql-5.1.73-3.el6_5.x86_64
RHSA-2014:0164 Moderate/Sec. mysql-devel-5.1.73-3.el6_5.x86_64
RHSA-2014:0164 Moderate/Sec. mysql-libs-5.1.73-3.el6_5.x86_64
RHSA-2014:0164 Moderate/Sec. mysql-server-5.1.73-3.el6_5.x86_64
RHBA-2014:0158 bugfix nss-sysinit-3.15.3-6.el6_5.x86_64
RHBA-2014:0158 bugfix nss-tools-3.15.3-6.el6_5.x86_64
If you want to apply only one specific advisory:
# yum update --advisory=RHSA-2014:0159
However, if you would like to know more information about this advisory before to apply it:
# yum updateinfo RHSA-2014:0159
Similarly, you can view CVEs which affect the system with:
# yum updateinfo list cves
Loaded plugins: auto-update-debuginfo, product-id, search-disabled-repos, subscription-manager
CVE-2017-1000380 Moderate/Sec. kernel-3.10.0-693.11.1.el7.x86_64
CVE-2017-1000380 Moderate/Sec. kernel-devel-3.10.0-693.11.1.el7.x86_64
CVE-2017-1000380 Moderate/Sec. kernel-headers-3.10.0-693.11.1.el7.x86_64
CVE-2017-1000380 Moderate/Sec. kernel-tools-3.10.0-693.11.1.el7.x86_64
CVE-2017-1000380 Moderate/Sec. kernel-tools-libs-3.10.0-693.11.1.el7.x86_64
CVE-2017-1000380 Moderate/Sec. perf-3.10.0-693.11.1.el7.x86_64
CVE-2017-1000380 Moderate/Sec. python-perf-3.10.0-693.11.1.el7.x86_64
CVE-2016-10002 Moderate/Sec. squid-7:3.5.20-2.el7_3.2.x86_64
updateinfo list done
For more commands consult the manual pages of yum-security with
# man yum-security
If you face any missing dependency issue while applying security patches on system then refer to yum update --security fails with missing dependency errors.
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
18 Comments
For those seeking to discover what CVEs are addressed in a given existing RPM, try this method that Marc Milgram from Red Hat kindly provided at this discussion.
1) First download the specific rpm you are interested in.
2) Use the below command...
Additionally,
If you are interested to see if a given CVE, or list of CVEs are applicable, you can use this method:
1) get the list of all applicable CVEs from Red Hat you wish,
- If you wanted to limit the search to a specific rpm such as "openssl", then at that above Red Hat link, you can enter "openssl" and filter out only openssl items, or filter against any other search term
- Place these into a file, one line after another, such as this limited example:
NOTE: These CVEs below are from limiting the CVEs to "openssl" in the manner I described above, and the list is not completed, there are plenty more for your date range.
2) Keep in mind the information in the article in this page, and run something like the following as root (a "for loop" will work in a bash shell):
And if the cve applies, it will prompt you to take the update, if it does not apply, it will tell you
Alternatively, I used this "echo n |" prior to the "yum update" exit the yum command with "n" if it found a hit:
Then redirect the output to another file to make your determinations.
I would like to create a puppet fact that would tell me the last security update applied to a box, what would by the best way to find out from the system when was the last security update applied?
'yum info-sec' actually lists all patches, you need to use 'yum info-sec --security'
Hello,
I'm trying to do this "yum updateinfo list" in Red Hat Enterprise Linux 5.11 and doesn't work, the version of plugin is:
yum-security-1.1.16-21.el5
Regards
Following statement is not right:
"For both Red Hat Enterprise Linux 5, 6, and 7"
It should be
"For Red Hat Enterprise Linux 5, 6, and 7"
I am trying to automate just SECURITY update my redhat servers. On redhat 7.1 I have edited "/etc/yum/yum-cron.conf" and put " update_cmd = security" in that file, which I hope it is right. But I can not find possibility to do it on redhat 6.x. What I was able to do was to edit file " /etc/sysconfig/yum-cron" and add the line " YUM_PARAMETER="--exclude='kernel' --exclude='grub'" which is not the same. I have commit following commandds:
yum install yum-plugin-security yum install yum-cron chkconfig yum-cron on service yum-cron start service yum-cron statusHow can I configure automate just SECURITY update on redhat 6.x?
How is this the Severity information of RHSA updated populated?
Specifically the article shows the following output:
On all of my systems, the output seems to be missing the severity information:
I can't see how to configure it to transform "security" to "Severity/Sec."
same in here, what I did was use info-sec with filters, like below:
What's annoying is that "yum update --security" shows 20 packages to update for security but when listing the installable errata in Satellite it shows 102 errata available and yet all those errata don't contain the errata.
You might hit https://bugzilla.redhat.com/show_bug.cgi?id=1408508 where metadata generated has empty package list for some errata in some circumstances, causing
yumthinks such an errata is not applicable (as no package would be updated by applying that errata).I recommend finding out one of the errata that Sat WebUI offers but
yumisnt aware of, and(z)grepthat errata id withinyumcache - if there will be something like:with no package in it, you hit that bug.
Wasn't there a KB article on this as well, do you have that link on how to fix it?
There hasnt been any - I just wrote https://access.redhat.com/solutions/3087631 .
The BZ is fixed in Satellite 6.2.10 we are about to release now.
I've got an interesting requirement in that a customer wants to only allow updates of packages with attached security errata (to limit unecessary drift/update of the OS platform). ie. restrict, warn or block the use of generic 'yum update' by an admin as it will update all packages.
There are other approaches which I have currently implemented, including limiting what is made available to the servers through Satellite so yum update doesn't 'see' non security errata.. but I guess what i'm really interested in is limiting (through client config) the inadvertant use "yum update" by an administrator, or redirecting/mapping 'yum update' to 'yum update --security'. I appreciate an admin can work around any restriction, but it's really to limit accidental use of full 'yum update' by well intentioned admins.
Current approaches are to alias yum, move yum and write a shim in its place (to warn/redirect if yum update is called), or patch the yum package itself (which i'd like to avoid). Any other suggestions appreciated.
why not creating a specific content-view for security patch purpose ?
In that content-view, you create a filter that filters only security updates.
In your patch management process, you can create a script that change on the fly the content-view of a host (or host-group) then apply security patches, and finally switching back to the original content-view (if you let to the admin the possibility to install additional programms if necessary).
hope this helps
.
Hi,
Is it necessary to reboot system after applying security updates ?
If it's a kernel update, you will have to. For other packages, it's recommended as to ensure that you are not still running the old libraries in memory. If you are just patching one particular independent service (ie, http), you can probably get away without a full system reboot.
More information can be found in the solution Which packages require a system reboot after the update? .