Menu
AWS Systems Manager
User Guide

How Patch Baseline Rules Work on Linux-Based Systems

The rules in a patch baseline for Linux distributions operate differently based on the distribution type. Unlike patch updates on Windows instances, rules are evaluated on each instance to take the configured repos on the instance into consideration. Patch Manager uses the native package manager to drive the installation of patches approved by the patch baseline.

How Patch Baseline Rules Work on Amazon Linux

On Amazon Linux, the patch selection process is as follows:

  1. On the instance, the YUM library accesses the updateinfo.xml file for each configured repo.

    Note

    The updateinfo.xml file might not be available if the repo is not one managed by Amazon. If there is no updateinfo.xml found, no patch will be applied.

  2. Each update notice in updateinfo.xml includes several attributes that denote the properties of the packages in the notice, as described in the following table.

    Update Notice Attributes

    Attribute Description
    type

    Corresponds to the value of the Classification key attribute in the patch baseline's PatchFilter data type. Denotes the type of package included in the update notice.

    Possible values:

    • Security

    • Bugfix

    • Enhancement

    • Recommended

    • Newpackage

    severity

    Corresponds to the value of the Severity key attribute patch baseline's PatchFilter data type. Denotes the severity of the packages included in the update notice. Usually only applicable for Security update notices.

    Possible values:

    • Critical

    • Important

    • Medium

    • Low

    update_id

    Denotes the advisory ID, such as ALAS-2017-867. The advisory ID can be used in the ApprovedPatches or RejectedPatches attribute in the patch baseline.

    references

    Contains additional information about the update notice, such as a CVE ID (format: CVE-2017-1234567). The CVE ID can be used in the ApprovedPatches or RejectedPatches attribute in the patch baseline.

    updated

    Corresponds to ApproveAfterDays in the patch baseline. Denotes the released date (updated date) of the packages included in the update notice. A comparison between the current timestamp and the value of this attribute plus the ApproveAfterDays is used to determine if the patch is approved for deployment.

  3. The product of the instance is determined by the SSM Agent. This attribute corresponds to the value of the Product key attribute in the patch baseline's PatchFilter data type.

  4. For each update notice in updateinfo.xml, the patch baseline is used as a filter, allowing only the qualified packages to be included in the update. If multiple packages are applicable after applying the patch baseline definition, the latest version is used.

How Patch Baseline Rules Work on RHEL

On Red Hat Enterprise Linux, the patch selection process is as follows:

  1. On the instance, the YUM library accesses the updateinfo.xml file for each configured repo.

    Note

    The updateinfo.xml file might not be available if the repo is not one managed by Red Hat. If there is no updateinfo.xml found, no patch will be applied.

  2. Each update notice in updateinfo.xml includes several attributes that denote the properties of the packages in the notice, as described in the following table.

    Update Notice Attributes

    Attribute Description
    type

    Corresponds to the value of the Classification key attribute in the patch baseline's PatchFilter data type. Denotes the type of package included in the update notice.

    Possible values:

    • Security

    • Bugfix

    • Enhancement

    • Recommended

    • Newpackage

    severity

    Corresponds to the value of the Severity key attribute in the patch baseline's PatchFilter data type. Denotes the severity of the packages included in the update notice. Usually only applicable for Security update notices.

    Possible values:

    • Critical

    • Important

    • Moderate

    • Low

    • None (If no severity is specified in the update notice or is an empty string.)

    update_id

    Denotes the advisory ID, such as RHSA-2017:0864. The advisory ID can be used in the ApprovedPatches or RejectedPatches attribute in the patch baseline.

    references

    Contains additional information about the update notice, such as a CVE ID (format: CVE-2017-1000371) or a Bugzilla ID (format: 1463241). The CVE ID and Bugzilla ID can be used in the ApprovedPatches or RejectedPatches attribute in the patch baseline.

    updated

    Corresponds to ApproveAfterDays in the patch baseline. Denotes the released date (updated date) of the packages included in the update notice. A comparison between the current timestamp and the value of this attribute plus the ApproveAfterDays is used to determine if the patch is approved for deployment.

  3. The product of the instance is determined by the SSM Agent. This attribute corresponds to the value of the Product key attribute in the patch baseline's PatchFilter data type.

  4. For each update notice in updateinfo.xml, the patch baseline is used as a filter, allowing only the qualified packages to be included in the update. If multiple packages are applicable after applying the patch baseline definition, the latest version is used.

How Patch Baseline Rules Work on Ubuntu Server

On Ubuntu Server, the patch baseline service offers filtering on the Priority and Section fields. These fields are typically present for all Ubuntu Server packages. To determine whether a patch is selected by the patch baseline, Patch Manager does the following:

  1. On Ubuntu systems, the equivalent of sudo apt-get update is run to refresh the list of available packages. Repos are not configured and the data is pulled from repos configured in a sources list.

  2. Next, the GlobalFilters, ApprovalRules, ApprovedPatches and RejectedPatches lists are applied. Only packages with candidate versions appearing in the distribution security repo (archive) are selected. For Ubuntu Server 14 this is repo is trusty-security.

To view the contents of the Priority and Section fields, run the following aptitude command:

Note

You may need to first install Aptitude on Ubuntu Server 16 systems.

aptitude search -F '%p %P %s %t %V#' '~U'

In the response to this command, all upgradable packages are reported in this format:

name, priority, section, archive, candidate version

For Ubuntu Server 14, the rules for package classification into the different compliance states are as follows:

  • Installed: Packages that are filtered through the patch baseline, with the candidate version appearing in trusty-security, and are not upgradable.

  • Missing: Packages that are filtered through the baseline, with the candidate version appearing in trusty-security, and are upgradable.

  • Installed Other: Packages that are not filtered through the baseline, with the candidate version appearing in trusty-security, and are not upgradable. The compliance level for these packages is set to UNSPECIFIED.

  • NotApplicable: Packages that are included in ApprovedPatches but are not installed on the system.

  • Failed: Packages that failed to install during the patch operation.

How Patch Baseline Rules Work on SUSE Linux Enterprise Server

On SLES, each patch includes the following attributes that denote the properties of the packages in the patch:

  • Category: Corresponds to the value of the Classification key attribute in the patch baseline's PatchFilter data type. Denotes the type of patch included in the update notice. Available options include:

    • Security

    • Recommended

    • Optional

    • Features

    • Document

    • Yast

  • Severity: Corresponds to the value of the Severity key attribute patch baseline's PatchFilter data type. Denotes the severity of the patches. Available options include:

    • None

    • Low

    • Moderate

    • Important

    • Critical

The product of the instance is determined by the SSM Agent. This attribute corresponds to the value of the Product key attribute in the patch baseline's PatchFilter data type.

For each patch, the patch baseline is used as a filter, allowing only the qualified packages to be included in the update. If multiple packages are applicable after applying the patch baseline definition, the latest version is used.