How patch baseline rules work on Linux-based systems - AWS Systems Manager

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 Server 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 and Amazon Linux 2

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

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

    Note

    If no updateinfo.xml file is 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.

    You can view the list of supported values by using the AWS CLI command describe-patch-properties or the API action DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.

    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.

    You can view the list of supported values by using the AWS CLI command describe-patch-properties or the API action DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.

    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.

    Note

    For information about accepted formats for lists of approved patches and rejected patches, see About package name formats for approved and rejected patch lists.

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

  4. Packages are selected for the update according to the following guidelines:

    Security option Patch selection

    Pre-defined default patch baselines provided by AWS and custom patch baselines where the Approved patches include non-security updates is not selected

    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.

    The equivalent yum command for this workflow is:

    sudo yum update-minimal --sec-severity=critical,important --bugfix -y

    Custom patch baselines where the Approved patches include non-security updates is selected

    In addition to applying the security updates that have been selected from updateinfo.xml, Patch Manager will apply nonsecurity updates that otherwise meet the patch filtering rules.

    The equivalent yum command for this workflow is:

    sudo yum update --security --bugfix -y

For information about patch compliance status values, see About patch compliance status values.

How patch baseline rules work on CentOS

On CentOS, the patch selection process is as follows:

  1. On the instance, the YUM library (on CentOS 6.x and 7.x versions) or the DNF library (on CentOS 8.x) 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 Oracle. 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.

    You can view the list of supported values by using the AWS CLI command describe-patch-properties or the API action DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.

    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.

    You can view the list of supported values by using the AWS CLI command describe-patch-properties or the API action DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.

    update_id

    Denotes the advisory ID, such as CVE-2019-17055. 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-2019-17055) 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.

    Note

    For information about accepted formats for lists of approved patches and rejected patches, see About package name formats for approved and rejected patch lists.

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

  4. Packages are selected for the update according to the following guidelines:

    Security option Patch selection

    Pre-defined default patch baselines provided by AWS and custom patch baselines where the Approved patches include non-security updates is not selected

    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.

    For CentOS 6 and 7, the equivalent yum command for this workflow is:

    sudo yum update-minimal --sec-severity=critical,important --bugfix -y

    For CentOS 8, the equivalent dnf commands for this workflow are:

    sudo dnf update-minimal --sec-severity=Critical --bugfix -y \ sudo dnf update-minimal --sec-severity=Important --bugfix -y

    Custom patch baselines where the Approved patches include non-security updates is selected

    In addition to applying the security updates that have been selected from updateinfo.xml, Patch Manager will apply nonsecurity updates that otherwise meet the patch filtering rules.

    For CentOS 6 and 7, the equivalent yum command for this workflow is:

    sudo yum update --security --bugfix -y

    For CentOS 8, the equivalent dnf command for this workflow is:

    sudo dnf update --security --bugfix -y

For information about patch compliance status values, see About patch compliance status values.

How patch baseline rules work on Debian

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

  1. On Debian 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.

    Important

    On Debian 8 only: Because Debian 8.* operating systems refer to an obsolete package repository (jessie-backports), Patch Manager performs the following additional steps to ensure that patching operations succeed:

    1. On your instance, the reference to the jessie-backports repository is commented out from the source location list (/etc/apt/sources.list.d/jessie-backports). As a result, no attempt is made to download patches from that location.

    2. A Stretch security update signing key is imported. This key provides the necessary permissions for the update and install operations on Debian 8.* distributions.

    3. An apt-get operation is run to ensure that the latest version of python3-apt is installed before the patching process begins.

    4. After the installation process completes, the reference to the jessie-backports repository is restored and the signing key is removed from the apt sources keyring. This is done to leave the system configuration as it was before the patching operation.

  2. Next, the GlobalFilters, ApprovalRules, ApprovedPatches and RejectedPatches lists are applied.

    Note

    Because it's not possible to reliably determine the release dates of update packages for Debian, the auto-approval options are not supported for this operating system.

    Only packages with candidate versions appearing in the distribution security repo (archive) are selected. For Debian 8 this is repo is debian-security jessie. For Debian 9, it is debian-security stretch.

    Note

    For information about accepted formats for lists of approved patches and rejected patches, see About package name formats for approved and rejected patch lists.

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

Note

You may need to first install Aptitude on Debian 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 information about patch compliance status values, see About patch compliance status values.

How patch baseline rules work on Oracle Linux

On Oracle 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 Oracle. 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.

    You can view the list of supported values by using the AWS CLI command describe-patch-properties or the API action DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.

    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.

    You can view the list of supported values by using the AWS CLI command describe-patch-properties or the API action DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.

    update_id

    Denotes the advisory ID, such as CVE-2019-17055. 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-2019-17055) 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.

    Note

    For information about accepted formats for lists of approved patches and rejected patches, see About package name formats for approved and rejected patch lists.

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

  4. Packages are selected for the update according to the following guidelines:

    Security option Patch selection

    Pre-defined default patch baselines provided by AWS and custom patch baselines where the Approved patches include non-security updates is not selected

    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.

    The equivalent yum command for this workflow is:

    sudo yum update-minimal --sec-severity=important,moderate --bugfix -y

    Custom patch baselines where the Approved patches include non-security updates is selected

    In addition to applying the security updates that have been selected from updateinfo.xml, Patch Manager will apply nonsecurity updates that otherwise meet the patch filtering rules.

    The equivalent yum command for this workflow is:

    sudo yum update --security --bugfix

For information about patch compliance status values, see About patch compliance status values.

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 (RHEL 7) or the DNF library (RHEL 8) 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.

    You can view the list of supported values by using the AWS CLI command describe-patch-properties or the API action DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.

    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.

    You can view the list of supported values by using the AWS CLI command describe-patch-properties or the API action DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.

    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.

    Note

    For information about accepted formats for lists of approved patches and rejected patches, see About package name formats for approved and rejected patch lists.

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

  4. Packages are selected for the update according to the following guidelines:

    Security option Patch selection

    Pre-defined default patch baselines provided by AWS and custom patch baselines where the Approved patches include non-security updates is not selected

    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.

    For RHEL 7, the equivalent yum command for this workflow is:

    sudo yum update-minimal --sec-severity=critical,important --bugfix -y

    For RHEL 8, the equivalent yum commands for this workflow are:

    sudo dnf update-minimal --sec-severity=Critical --bugfix -y \ sudo dnf update-minimal --sec-severity=Important --bugfix -y

    Custom patch baselines where the Approved patches include non-security updates is selected

    In addition to applying the security updates that have been selected from updateinfo.xml, Patch Manager will apply nonsecurity updates that otherwise meet the patch filtering rules.

    For RHEL 7, the equivalent yum command for this workflow is:

    sudo yum update --security --bugfix

    For RHEL 8, the equivalent dnf command for this workflow is:

    sudo dnf update --security --bugfix

For information about patch compliance status values, see About patch compliance status values.

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.

    You can view the list of supported values by using the AWS CLI command describe-patch-properties or the API action DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.

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

    You can view the list of supported values by using the AWS CLI command describe-patch-properties or the API action DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.

The product of the instance is determined by 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.

Note

For information about accepted formats for lists of approved patches and rejected patches, see About package name formats for approved and rejected patch lists.

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 Server 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.

    Note

    Because it's not possible to reliably determine the release dates of update packages for Ubuntu Server, the auto-approval options are not supported for this operating system.

    Only packages with candidate versions appearing in the distribution security repo (archive) are selected. For Ubuntu Server 14 this is repo is trusty-security. For Ubuntu Server 16, it is xenial-security.

    Note

    For information about accepted formats for lists of approved patches and rejected patches, see About package name formats for approved and rejected patch lists.

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 information about patch compliance status values, see About patch compliance status values.