AWS systems-manager documentation change
Summary
Removed references to deprecated or unsupported Linux distributions (Amazon Linux 1, Amazon Linux 2022, CentOS, CentOS Stream, SUSE Linux Enterprise Server, Raspberry Pi OS) and updated documentation to focus on current supported systems. Simplified Debian Server section by removing obsolete steps for Debian 8 and version-specific repos.
Security assessment
The changes primarily remove outdated content and streamline documentation for currently supported systems. There is no evidence of addressing a specific security vulnerability or adding new security features. Updates to command syntax (YUM/DNF) and removal of EOL distributions are maintenance tasks rather than security fixes.
Diff
diff --git a/systems-manager/latest/userguide/patch-manager-linux-rules.md b/systems-manager/latest/userguide/patch-manager-linux-rules.md index 9fb854007..e6edd7def 100644 --- a//systems-manager/latest/userguide/patch-manager-linux-rules.md +++ b//systems-manager/latest/userguide/patch-manager-linux-rules.md @@ -5 +5 @@ -How patch baseline rules work on Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022 and Amazon Linux 2023How patch baseline rules work on CentOS and CentOS StreamHow patch baseline rules work on Debian Server and Raspberry Pi OSHow patch baseline rules work on macOSHow patch baseline rules work on Oracle LinuxHow patch baseline rules work on AlmaLinux, RHEL, and Rocky LinuxHow patch baseline rules work on SUSE Linux Enterprise ServerHow patch baseline rules work on Ubuntu Server +How patch baseline rules work on Amazon Linux 2 and Amazon Linux 2023How patch baseline rules work on Debian ServerHow patch baseline rules work on macOSHow patch baseline rules work on Oracle LinuxHow patch baseline rules work on AlmaLinux, RHEL, and Rocky LinuxHow patch baseline rules work on Ubuntu Server @@ -15 +15 @@ For Linux-based operating system types that report a severity level for patches, - * How patch baseline rules work on Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022 and Amazon Linux 2023 + * How patch baseline rules work on Amazon Linux 2 and Amazon Linux 2023 @@ -17,3 +17 @@ For Linux-based operating system types that report a severity level for patches, - * How patch baseline rules work on CentOS and CentOS Stream - - * How patch baseline rules work on Debian Server and Raspberry Pi OS + * How patch baseline rules work on Debian Server @@ -27,2 +24,0 @@ For Linux-based operating system types that report a severity level for patches, - * How patch baseline rules work on SUSE Linux Enterprise Server - @@ -34 +30 @@ For Linux-based operating system types that report a severity level for patches, -## How patch baseline rules work on Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022 and Amazon Linux 2023 +## How patch baseline rules work on Amazon Linux 2 and Amazon Linux 2023 @@ -40 +36 @@ Amazon Linux 2023 (AL2023) uses versioned repositories that can be locked to a s -On Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022 and Amazon Linux 2023, the patch selection process is as follows: +On Amazon Linux 2 and Amazon Linux 2023, the patch selection process is as follows: @@ -42 +38 @@ On Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022 and Amazon Linux 2023, the - 1. On the managed node, the YUM library (Amazon Linux 1 and, Amazon Linux 2) or the DNF library (Amazon Linux 2022 and Amazon Linux 2023) accesses the `updateinfo.xml` file for each configured repo. + 1. On the managed node, the YUM library (Amazon Linux 2) or the DNF library (Amazon Linux 2023) accesses the `updateinfo.xml` file for each configured repo. @@ -64 +60 @@ Security option | Patch selection -Pre-defined default patch baselines provided by AWS and custom patch baselines where the **Include non-security updates** check box 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 Amazon Linux 1 and Amazon Linux 2, the equivalent yum command for this workflow is: +Pre-defined default patch baselines provided by AWS and custom patch baselines where the **Include non-security updates** check box 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 Amazon Linux 2, the equivalent yum command for this workflow is: @@ -68 +64 @@ Pre-defined default patch baselines provided by AWS and custom patch baselines w -For Amazon Linux 2022 and Amazon Linux 2023, the equivalent dnf command for this workflow is: +For Amazon Linux 2023, the equivalent dnf command for this workflow is: @@ -72 +68 @@ For Amazon Linux 2022 and Amazon Linux 2023, the equivalent dnf command for this -Custom patch baselines where the **Include non-security updates** check box _is_ selected with a SEVERITY list of `[Critical, Important] `and a CLASSIFICATION list of `[Security, Bugfix]` | In addition to applying the security updates that were selected from `updateinfo.xml`, Patch Manager applies nonsecurity updates that otherwise meet the patch filtering rules. For Amazon Linux and Amazon Linux 2, the equivalent yum command for this workflow is: +Custom patch baselines where the **Include non-security updates** check box _is_ selected with a SEVERITY list of `[Critical, Important] `and a CLASSIFICATION list of `[Security, Bugfix]` | In addition to applying the security updates that were selected from `updateinfo.xml`, Patch Manager applies nonsecurity updates that otherwise meet the patch filtering rules. For Amazon Linux 2, the equivalent yum command for this workflow is: @@ -76 +72 @@ Custom patch baselines where the **Include non-security updates** check box _is_ -For Amazon Linux 2022 and Amazon Linux 2023, the equivalent dnf command for this workflow is: +For Amazon Linux 2023, the equivalent dnf command for this workflow is: @@ -89,23 +85 @@ For information about patch compliance status values, see [Patch compliance stat -## How patch baseline rules work on CentOS and CentOS Stream - -The CentOS and CentOS Stream default repositories do not include an `updateinfo.xml` file. However, custom repositories that you create or use might include this file. In this topic, references to `updateinfo.xml` apply only to these custom repositories. - -On CentOS and CentOS Stream, the patch selection process is as follows: - - 1. On the managed node, the YUM library (on CentOS 6.x and 7.x versions) or the DNF library (on CentOS 8.x and CentOS Stream) accesses the `updateinfo.xml` file, if it exists in a custom repository, for each configured repo. - -If there is no `updateinfo.xml` found, which always includes the default repos, whether patches are installed depends on settings for **Include non-security updates** and **Auto-approval**. For example, if non-security updates are permitted, they're installed when the auto-approval time arrives. - - 2. If `updateinfo.xml` is present, each update notice in the file 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](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 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](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** or the API operation **[DescribePatchProperties](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**. 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](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 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](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** or the API operation **[DescribePatchProperties](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**. 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](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) or [RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-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](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) or [RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) attribute in the patch baseline. -updated | Corresponds to [ApproveAfterDays](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchRule.html#EC2-Type-PatchRule-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. - -For information about accepted formats for lists of approved patches and rejected patches, see [Package name formats for approved and rejected patch lists](./patch-manager-approved-rejected-package-name-formats.html). - - 3. In all cases, the product of the managed node is determined by SSM Agent. This attribute corresponds to the value of the Product key attribute in the patch baseline's [PatchFilter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) data type. +## How patch baseline rules work on Debian Server @@ -113,11 +87 @@ For information about accepted formats for lists of approved patches and rejecte - 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 **Include non-security updates** check box is _not_ selected | For each update notice in `updateinfo.xml`, if it exists in a custom repository, 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 where `updateinfo.xml` is present, the equivalent yum command for this workflow is: - - sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y - -For CentOS 8 and CentOS Stream where `updateinfo.xml` is present, the equivalent dnf command for this workflow is: - - sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y +On Debian Server , the patch baseline service offers filtering on the _Priority_ and _Section_ fields. These fields are typically present for all Debian Server packages. To determine whether a patch is selected by the patch baseline, Patch Manager does the following: @@ -125,24 +89 @@ For CentOS 8 and CentOS Stream where `updateinfo.xml` is present, the equivalent -Custom patch baselines where the **Include non-security updates** check box _is_ selected with a SEVERITY list of `[Critical, Important]` and a CLASSIFICATION list of `[Security, Bugfix]` | In addition to applying the security updates that were selected from `updateinfo.xml`, if it exists in a custom repository, Patch Manager applies nonsecurity updates that otherwise meet the patch filtering rules. For CentOS 6 and 7 where `updateinfo.xml` is present, the equivalent yum command for this workflow is: - - sudo yum update --sec-severity=Critical,Important --bugfix -y - -For CentOS 8 and CentOS Stream where `updateinfo.xml` is present, the equivalent dnf command for this workflow is: - - sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y - -For default repos and custom repos without `updateinfo.xml`, you _must_ select the **Include non-security updates** check box in order to update operating system (OS) packages. - -###### Note - -New packages that replace now-obsolete packages with different names are installed if you run these `yum` or `dnf` commands outside of Patch Manager. However, they are _not_ installed by the equivalent Patch Manager operations. - - - - -For information about patch compliance status values, see [Patch compliance state values](./patch-manager-compliance-states.html). - -## How patch baseline rules work on Debian Server and Raspberry Pi OS - -On Debian Server and Raspberry Pi OS (formerly Raspbian), the patch baseline service offers filtering on the _Priority_ and _Section_ fields. These fields are typically present for all Debian Server and Raspberry Pi OS packages. To determine whether a patch is selected by the patch baseline, Patch Manager does the following: - - 1. On Debian Server and Raspberry Pi OS systems, the equivalent of `sudo apt-get update` is run to refresh the list of available packages. Repos aren't configured and the data is pulled from repos configured in a `sources` list. + 1. On Debian Server systems, the equivalent of `sudo apt-get update` is run to refresh the list of available packages. Repos aren't configured and the data is pulled from repos configured in a `sources` list. @@ -152,12 +92,0 @@ On Debian Server and Raspberry Pi OS (formerly Raspbian), the patch baseline ser -###### Important - -On Debian Server 8 only: Because Debian Server 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 managed node, 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 Server 8.* distributions. - - 3. The `apt-get` operation is run at this point to ensure that the latest version of `python3-apt` is installed before the patching process begins. - - 4. After the installation process is complete, 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. - @@ -176,6 +104,0 @@ These repos are named as follows: - * Debian Server 8: `debian-security jessie` - - * Debian Server and Raspberry Pi OS 9: `debian-security stretch` - - * Debian Server 10: `debian-security buster` - @@ -337,21 +259,0 @@ For information about patch compliance status values, see [Patch compliance stat -## 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](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 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](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** or the API operation **[DescribePatchProperties](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**. 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](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 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](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** or the API operation **[DescribePatchProperties](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**. 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 managed node is determined by SSM Agent. This attribute corresponds to the value of the **Product** key attribute in the patch baseline's [PatchFilter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 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. - -For information about accepted formats for lists of approved patches and rejected patches, see [Package name formats for approved and rejected patch lists](./patch-manager-approved-rejected-package-name-formats.html). - @@ -376,2 +277,0 @@ If nonsecurity updates are excluded, an implicit rule is applied in order to sel - * Ubuntu Server 14.04 LTS: `trusty-security` - @@ -384,2 +283,0 @@ If nonsecurity updates are excluded, an implicit rule is applied in order to sel - * Ubuntu Server 20.10 STR: `groovy-security` - @@ -388,4 +285,0 @@ If nonsecurity updates are excluded, an implicit rule is applied in order to sel - * Ubuntu Server 23.04 (`lunar-security`) - - * Ubuntu Server 23.10 (`mantic-security`) - @@ -394,2 +287,0 @@ If nonsecurity updates are excluded, an implicit rule is applied in order to sel - * Ubuntu Server 24.10 (`oracular-security`) -