

# Security and Compliance in Amazon Linux 2023
<a name="security"></a>

**Important**  
 If you want to report a vulnerability or have a security concern regarding AWS cloud services or open source projects, contact AWS Security using the [Vulnerability Reporting page](https://aws.amazon.com/security/vulnerability-reporting/) 

Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations.

Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud:
+ **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to AL2023, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company's requirements, and applicable laws and regulations. 

**Topics**
+ [Amazon Linux Security advisories for AL2023](alas.md)
+ [Listing applicable Advisories](listing-applicable-advisories.md)
+ [Applying security updates in-place](security-inplace-update.md)
+ [Setting SELinux modes for AL2023](selinux-modes.md)
+ [Enable FIPS Mode on AL2023](fips-mode.md)
+ [Enable FIPS Mode in an AL2023 Container](fips-mode-container.md)
+ [Swap OpenSSL FIPS providers on AL2023](fips-openssl-swap-provider.md)
+ [AL2023 Kernel Hardening](kernel-hardening.md)
+ [Repository metadata signing in AL2023](repo-metadata-signing.md)
+ [UEFI Secure Boot on AL2023](uefi-secure-boot.md)

# Amazon Linux Security advisories for AL2023
<a name="alas"></a>

 Although we work hard to make Amazon Linux secure, at times there will be security issues that require fixing. An *advisory* is issued when a fix is available. The primary location where we publish advisories is the Amazon Linux Security Center (ALAS). For more information, see [Amazon Linux Security Center](https://alas.aws.amazon.com/alas2023.html). 

**Important**  
 If you want to report a vulnerability or have a security concern regarding AWS cloud services or open source projects, contact AWS Security using the [Vulnerability Reporting page](https://aws.amazon.com/security/vulnerability-reporting/) 

 Information on issues and the relevant updates that affect AL2023 are published by the Amazon Linux team in several locations. It's common for security tooling to fetch information from these primary sources and present the results to you. As such, you might not directly interact with the primary sources that Amazon Linux publishes, but instead the interface provided by your preferred tooling, such as [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html). 

## Amazon Linux Security Center announcements
<a name="alas-announcements"></a>

 Amazon Linux *announcements* are provided for items that do not fit into an advisory. This section contains announcements about ALAS itself, along with information that does not fit in an advisory. For more information, see [Amazon Linux Security Center (ALAS) Announcements](https://alas.aws.amazon.com/announcements.html). 

 For example, the [2021-001 - Amazon Linux Hotpatch Announcement for Apache Log4j](https://alas.aws.amazon.com/announcements/2021-001.html) fit into an announcement rather than an advisory. In this announcement, Amazon Linux added a package to help customers mitigate a security issue in software that was not part of Amazon Linux. 

 The [Amazon Linux Security Center CVE Explorer](https://explore.alas.aws.amazon.com/) was also announced on ALAS announcements. For more information, see [New website for CVEs](https://alas.aws.amazon.com/announcements/2023-001.html). 

## Amazon Linux Security Center Frequently Asked Questions
<a name="alas-faqs"></a>

 For answers to some frequently asked questions about ALAS and how Amazon Linux evaluates CVEs, see [Amazon Linux Security Center (ALAS) Frequently Asked Questions (FAQs)](https://alas.aws.amazon.com/faqs.html). 

## ALAS Advisories
<a name="alas-advisories"></a>

 An Amazon Linux Advisory contains important information relevant to Amazon Linux users, typically information about security updates. The [Amazon Linux Security Center](https://alas.aws.amazon.com/alas2023.html) is where Advisories are visible on the web. Advisory information is also part of the RPM package repository metadata. 

## Advisories and RPM repositories
<a name="advisory-and-repos"></a>

 An Amazon Linux 2023 package repository may contain metadata describing zero or more updates. The `dnf updateinfo` command is named after the repository metadata filename which contains this information, `updateinfo.xml`. While the command is named `updateinfo`, and the metadata file refers to an `update`, these all refer to package updates which are part of an Advisory. 

 Amazon Linux Advisories are published on the [Amazon Linux Security Center](https://alas.aws.amazon.com/alas2023.html) web site, along with information being present in the RPM repository metadata that the `dnf` package manager refers to. The web site and repository metadata are eventually consistent, and there may be inconsistencies in the information on the web site and in repository metadata. This will typically occur when a new release of AL2023 is in the process of being released, there has been an update to an Advisory after the most recent AL2023 release. 

 While it is typical for a new Advisory to be issued alongside the package update which addresses the issue, this is not always the case. An Advisory can be created for a new issue which is addressed in already released packages. An existing Advisory may also be updated with new CVEs which are addressed by the existing update. 

 The [Deterministic upgrades through versioned repositories on AL2023](deterministic-upgrades.md) feature of Amazon Linux 2023 means that the RPM repository for a particular AL2023 version contains a snapshot of the RPM repository metadata as of that version. This *includes* the metadata describing security updates. The RPM repository for particular AL2023 version *is not updated* after release. New or updated security advisories *will not be visible when looking at an older version of the AL2023 RPM repositories*. Refer to the [Listing applicable Advisories](listing-applicable-advisories.md) section for how to use the `dnf` package manager to look at either the `latest` repository version, or a specific AL2023 release. 

## Advisory IDs
<a name="advisory-ids"></a>

 Each Advisory is referred to by an `id`. It is currently a quirk of Amazon Linux where the [Amazon Linux Security Center](https://alas.aws.amazon.com/alas2023.html) web site will list an Advisory as [ALAS-2024-581](https://alas.aws.amazon.com/AL2023/ALAS-2024-581.html), while the `dnf` package manager will [list that advisory as having the ID of ALAS2023-2024-581](listing-applicable-advisories.md). When [Applying security updates in-place](security-inplace-update.md) the package manager ID needs to be used if referring to a specific Advisory. 

 For Amazon Linux, each major version of the OS has its own namespace of Advisory IDs. There should be no assumptions made as to the format of Amazon Linux Advisory IDs. Historically, Amazon Linux Advisory IDs have followed the pattern of `NAMESPACE-YEAR-NUMBER`. The full range of possible values for `NAMESPACE` is not defined, but has included `ALAS`, `ALASCORRETTO8`, `ALAS2023`, `ALAS2`, `ALASPYTHON3.8`, and `ALASUNBOUND-1.17`. The `YEAR` has been the year in which the advisory was created, and `NUMBER` being a unique integer within the namespace. 

 While Advisory IDs will *typically* be sequential and in the order the updates are released, there are many reasons why this could not be the case, so this should not be assumed. 

 Treat the Advisory ID as an opaque string which is unique to each major version of Amazon Linux. 

 In Amazon Linux 2, each Extra was in a separate RPM repository, and the Advisory metadata is contained only within the repository to which it is relevant. An Advisory for one repository *is not applicable* to another repository. On the [Amazon Linux Security Center](https://alas.aws.amazon.com/alas2.html) web site, there is currently one list of Advisories for each major Amazon Linux version, and it is not separated out into per-repository lists. 

 As AL2023 does not use the Extras mechanism to package alternate versions of packages, there are currently only two RPM repositories, each of which has Advisories, the `core` repository and the `livepatch` repository. The `livepatch` repository is for [Kernel Live Patching on AL2023](live-patching.md). 

## Advisory Released Date and Advisory Updated Date
<a name="advisory-dates"></a>

 The Advisory Released Date for Amazon Linux Advisories indicates when the security update was first made publicly available in the RPM repository. Advisories are posted on the [Amazon Linux Security Center](https://alas.aws.amazon.com/alas2023.html) web site immediately after fixes are made available for installation through the RPM repository. 

 The Advisory Updated Date indicates when new information was added to an advisory after it was previously published. 

 There should not be any assumptions made between the AL2023 version number (e.g. 2023.6.20241031) and the Advisory Released Date of Advisories published alongside that release. 

## Advisory Types
<a name="advisory-types"></a>

 The RPM repository metadata supports Advisories of different types. While Amazon Linux has near universally only issued Advisories which are security updates, this should not be assumed. It is possible that Advisories for events such as bug fixes, enhancements, and new packages could be issued, and the Advisory be marked as containing that type of update. 

## Advisory Severities
<a name="advisory-severities"></a>

 Each Advisory has its own Severity as each issue is evaluated separately. Multiple CVEs may be addressed in a single Advisory, and each CVE may have a different evaluation, but the Advisory itself has one Severity. There can be multiple Advisories referring to a single package update, thus there can be multiple Severities for a particular package update (one per Advisory). 

 In order of decreasing Severity, Amazon Linux has used Critical, Important, Moderate, and Low to indicate the Severity of an Advisory. Amazon Linux Advisories may also *not have a Severity*, although this is exceedingly rare. 

 Amazon Linux is one of the RPM based Linux distributions that uses the term Moderate, while some other RPM based Linux distributions use the equivalent term Medium. The Amazon Linux package manager treats both terms as equivalent, and third party package repositories may use the term Medium. 

 Amazon Linux Advisories can *change Severity* over time as more is learned about the relevant issues addressed in the Advisory. 

 The Severity of an Advisory will *typically* track the highest Amazon Linux evaluated CVSS score for the CVEs referenced by the Advisory. There may be cases where this is not the case. One example would be where there is an issue which is addressed for which there is not a CVE assigned. 

 See the [ALAS FAQ](https://alas.aws.amazon.com/faqs.html) for more information about how Amazon Linux uses Advisory severity ratings. 

## Advisories and Packages
<a name="advisory-packages"></a>

 There can be many Advisories for a single package, and not all packages will ever have an Advisory published for them. A particular package version can be referenced in multiple Advisories, each with its own Severity and CVEs. 

 It is possible for multiple Advisories for the same package update to be issued simultaneously in one new AL2023 release, or in rapid succession. 

 Like other Linux distributions, there can be one to many different binary packages built from the same source package. For example, [ALAS-2024-698](https://alas.aws.amazon.com/AL2023/ALAS-2024-698.html) is an Advisory listed on the [AL2023 section of the Amazon Linux Security Center web site](https://alas.aws.amazon.com/alas2023.html) as applying to the `mariadb105` package. This is the *source* package name, and the Advisory itself refers to the *binary* packages alongside the source package. In this case, over a dozen binary packages are built from the one `mariadb105` source package. While it is extremely common for there to be a binary package with the same name as the source package, this is not universal. 

 While Amazon Linux Advisories have typically listed all binary packages built from the updated source package, this should not be assumed. The package manager and RPM repository metadata format allows for Advisories that list a subset of the updated binary packages. 

 A particular Advisory may also only apply to a particular CPU Architecture. There can be packages that are not built for all architectures, or issues that do not affect all architectures. In the case where a package is available on all architectures but an issue applies only to one, Amazon Linux has typically not issued an Advisory only referencing only the affected architecture, although this should not be assumed. 

 Due to the nature of package dependencies, it is common that an Advisory references one package, but installing that update will require other package updates, including packages that are not listed in the Advisory. The `dnf` package manager will handle installing the required dependencies. 

## Advisories and CVEs
<a name="advisory-cves"></a>

 An Advisory may address zero or more CVEs, and there may be multiple Advisories referencing the same CVE. 

 An example of when an Advisory may reference zero CVEs is when a CVE is not yet (or ever) assigned to the issue. 

 An example of where multiple Advisories may reference the same CVE when (for example) the CVE is applicable to multiple packages. For example, [CVE-2024-21208](https://alas.aws.amazon.com/cve/html/CVE-2024-21208.html) applies to Corretto 8, 11, 17, and 21. Each of these Corretto versions is a separate package in AL2023, and there is an Advisory for each of these packages: [ALAS-2024-754](https://alas.aws.amazon.com/AL2023/ALAS-2024-754.html) for Corretto 8, [ALAS-2024-753](https://alas.aws.amazon.com/AL2023/ALAS-2024-753.html) for Corretto 11, [ALAS-2024-752](https://alas.aws.amazon.com/AL2023/ALAS-2024-752.html) for Corretto 17, and [ALAS-2024-752](https://alas.aws.amazon.com/AL2023/ALAS-2024-751.html) for Corretto 21. While these Corretto releases all have the same list of CVEs, this should not be assumed. 

 A particular CVE can be evaluated differently for different packages. For example, if a particular CVE is referenced in an Advisory with a Severity of Important, it is possible that another Advisory is issued referencing the same CVE with a different Severity. 

 The RPM repository metadata allows for a list of References for each Advisory. While Amazon Linux has typically only referenced CVEs, the metadata format does allow for other reference types. 

 The RPM package repository metadata will only refer to CVEs with a fix available. The [Explore section of the Amazon Linux Security Center](https://explore.alas.aws.amazon.com) web site contains information on CVEs that Amazon Linux has evaluated. This evaluation may result in a CVSS base score, Severity, and status for various Amazon Linux releases and packages. The status for a CVE for a particular Amazon Linux release or package may be Not Affected, Pending Fix, or No Fix Planned. The status and evaluation of CVEs may change many times and *in any way* prior to an Advisory being issued. This includes re-evaluation of the applicability of a CVE to Amazon Linux. 

 The list of CVEs referenced by an Advisory can change after initial publication of that Advisory. 

## Advisory Text
<a name="advisory-text"></a>

 An Advisory will also contain text describing the issue or issues that were the reason for creating the Advisory. It is common that this text will be the unmodified CVE text. This text may refer to upstream version numbers where a fix is available which are different from the package version that Amazon Linux has applied a fix to. It is common that Amazon Linux will back-port fixes from newer upstream releases. In the case where the Advisory text mentions an upstream release which is different than the version shipped in an Amazon Linux version, the Amazon Linux package versions in the Advisory will be accurate for Amazon Linux. 

 It is possible for the Advisory text in the RPM repository metadata to be placeholder text simply referring to the [Amazon Linux Security Center](https://alas.aws.amazon.com/alas2023.html) web site for details. 

## Kernel Live Patch Advisories
<a name="livepatch-advisories"></a>

 Advisories for live patches are unique in that they refer to a different package (the Linux kernel) than the package the Advisory is against (e.g. `kernel-livepatch-6.1.15-28.43`). 

 An Advisory for a [Kernel Live Patch](live-patching.md) will reference the issues (such as CVEs) which the particular Live Patch package can address for the *specific* kernel version to which the live patch package applies. 

 Each live patch is for a *specific* kernel version. In order to apply a live patch for a CVE, the right live patch package for your kernel version needs to be installed, and the live patch applied. 

 For example, [CVE-2023-6111](https://alas.aws.amazon.com/cve/html/CVE-2023-6111.html) can be live patched for AL2023 kernel versions `6.1.56-82.125`, `6.1.59-84.139`, and `6.1.61-85.141`. A new kernel version with a fix for this CVE was also released, and has [a separate advisory](https://alas.aws.amazon.com/AL2023/ALAS-2023-461.html). In order for [CVE-2023-6111](https://alas.aws.amazon.com/cve/html/CVE-2023-6111.html) to be addressed on AL2023 either a kernel version equal to or later than what [ALAS2023-2023-461](https://alas.aws.amazon.com/AL2023/ALAS-2023-461.html) specifies needs to be *running*, or one of the kernel versions with a live patch for this CVE needs to be running with the applicable livepatch applied. 

 When there are new live patches available for a specific kernel version which already has a live patch available, a new version of the `kernel-livepatch-KERNEL_VERSION` package is released. For example, the [https://alas.aws.amazon.com/AL2023/ALASLIVEPATCH-2023-003.html](https://alas.aws.amazon.com/AL2023/ALASLIVEPATCH-2023-003.html) Advisory was issued with the `kernel-livepatch-6.1.15-28.43-1.0-1.amzn2023` package which contained live patches for the `6.1.15-28.43` kernel covering three CVEs. Later, the [https://alas.aws.amazon.com/AL2023/ALASLIVEPATCH-2023-009.html](https://alas.aws.amazon.com/AL2023/ALASLIVEPATCH-2023-009.html) Advisory was issued with the `kernel-livepatch-6.1.15-28.43-1.0-2.amzn2023` package; an update to the previous live patch package for the `6.1.15-28.43` kernel containing live patches for another three CVEs. There were also other live patch Advisories issues for other kernel versions, with packages containing live patches for those specific kernel versions. 

 For more information on kernel live patching, see [Kernel Live Patching on AL2023](live-patching.md). 

 For anyone developing tools around security advisories, it is also recommended to look at the [XML Schema for Advisories and `updateinfo.xml`](#advisory-schema) section for more information. 

## XML Schema for Advisories and `updateinfo.xml`
<a name="advisory-schema"></a>

 The `updateinfo.xml` file is part of the package repository format. It is the metadata that the `dnf` package manager parses to implement functionality such as [Listing applicable Advisories](listing-applicable-advisories.md) and [Applying security updates in-place](security-inplace-update.md). 

 We recommended that the API of the `dnf` package manager is used rather than writing custom code to parse the repository metadata formats. The version of `dnf` in AL2023 can parse both the AL2023 and AL2 repository formats, and thus the API can be used to examine advisory information for either OS version. 

 The [RPM Software Management](https://github.com/rpm-software-management/) project documents the RPM metadata formats in the [rpm-metadata](https://github.com/rpm-software-management/rpm-metadata) repository on GitHub. 

 For those developing tools to directly parse the `updateinfo.xml` metadata, paying careful attention to the [rpm-metadata documentation](https://github.com/rpm-software-management/rpm-metadata) is strongly advised. The documentation covers what has been seen in the wild, which includes many exceptions to what you may reasonably interpret as a rule for the metadata format. 

 There is also a growing set of real-world examples of `updateinfo.xml` files in the [raw-historical-rpm-repository-examples](https://github.com/rpm-software-management/raw-historical-rpm-repository-examples) repository on GitHub. 

 In case anything is unclear in the documentation, you can open an issue on the GitHub project so that we can answer the question and update the documentation appropriately. As Open Source projects, pull requests updating documentation are also welcome. 

# Listing applicable Advisories
<a name="listing-applicable-advisories"></a>

 The `dnf` package manager has access to metadata describing what Advisories are fixed in what package versions. It can thus list what Advisories are applicable to an instance or container image. 

**Note**  
 Tools such as [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/) can use this functionality to show what updates are relevant across a fleet rather than just a single instance. 

 When listing updates, you can instruct `dnf` to look at the metadata of a particular AL2023 release, or the metadata from the latest release. 

**Note**  
 Once an AL2023 release is made, it is immutable. Thus, new or updated advisories on the [Amazon Linux Security Center](https://alas.aws.amazon.com/alas2023.html) are only added to the metadata of *new* releases of AL2023 

 We will now go through examples of looking at what advisories apply to some AL2023 container images. These commands all work on non-containerized environments such as EC2 instances. 

------
#### [ Listing advisories in a specific version ]

 In this example we are going to look at what advisories in the [2023.1.20230628](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.1.20230628.html) release are relevant in a container image of the [2023.0.20230315](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.0.20230315.html) release. 

**Note**  
 This example uses the [2023.0.20230315](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.0.20230315.html) and [2023.1.20230628](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.1.20230628.html) releases, and these *are not* the latest release of AL2023 See the [AL2023 Release Notes](https://docs.aws.amazon.com/linux/al2023/release-notes/) for the latest releases, which contain the latest security updates. 

 In this example we will be starting with a container image for the [2023.0.20230315](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.0.20230315.html) release. 

 First, we fetch this container image from the container registry. The `.0` at the end indicates the version of the image for a particular release; this image version is usually zero. 

```
$ docker pull public.ecr.aws/amazonlinux/amazonlinux:2023.0.20230315.0
	  2023.0.20230315.0: Pulling from amazonlinux/amazonlinux
b76f3b09316a: Pull complete
Digest: sha256:94e7183b0739140dbd5b639fb7600f0a2299cec5df8780c26d9cb409da5315a9
Status: Downloaded newer image for public.ecr.aws/amazonlinux/amazonlinux:2023.0.20230315.0
public.ecr.aws/amazonlinux/amazonlinux:2023.0.20230315.0
```

 We can now spawn a shell inside the container, from which we will ask `dnf` to list what advisories are relevant to the packages installed in the container. 

```
$ docker run -it public.ecr.aws/amazonlinux/amazonlinux:2023.0.20230315.0
	  bash-5.2#
```

 The `dnf updateinfo` command is now used to display a summary of what advisories in the [2023.1.20230628](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.1.20230628.html) release are relevant to our installed packages. 

```
$ dnf updateinfo --releasever=2023.1.20230628
Amazon Linux 2023 repository                     42 MB/s |  15 MB     00:00
Last metadata expiration check: 0:00:02 ago on Mon Jul 22 20:24:24 2024.
Updates Information Summary: available
    8 Security notice(s)
        1 Important Security notice(s)
        5 Medium Security notice(s)
        2 Low Security notice(s)
```

 To get a list of the advisories, the `--list` option can be given to `dnf updateinfo`. 

```
$ dnf updateinfo --releasever=2023.1.20230628 --list
Last metadata expiration check: 0:01:22 ago on Mon Jul 22 20:24:24 2024.
ALAS2023-2023-193 Medium/Sec.    curl-minimal-8.0.1-1.amzn2023.x86_64
ALAS2023-2023-225 Medium/Sec.    glib2-2.74.7-688.amzn2023.0.1.x86_64
ALAS2023-2023-195 Low/Sec.       libcap-2.48-2.amzn2023.0.3.x86_64
ALAS2023-2023-193 Medium/Sec.    libcurl-minimal-8.0.1-1.amzn2023.x86_64
ALAS2023-2023-145 Low/Sec.       libgcc-11.3.1-4.amzn2023.0.3.x86_64
ALAS2023-2023-145 Low/Sec.       libgomp-11.3.1-4.amzn2023.0.3.x86_64
ALAS2023-2023-145 Low/Sec.       libstdc++-11.3.1-4.amzn2023.0.3.x86_64
ALAS2023-2023-163 Medium/Sec.    libxml2-2.10.4-1.amzn2023.0.1.x86_64
ALAS2023-2023-220 Important/Sec. ncurses-base-6.2-4.20200222.amzn2023.0.4.noarch
ALAS2023-2023-220 Important/Sec. ncurses-libs-6.2-4.20200222.amzn2023.0.4.x86_64
ALAS2023-2023-181 Medium/Sec.    openssl-libs-1:3.0.8-1.amzn2023.0.2.x86_64
ALAS2023-2023-222 Medium/Sec.    openssl-libs-1:3.0.8-1.amzn2023.0.3.x86_64
```

------
#### [ Listing advisories in the latest version ]

 In this example we are going to look at what updates are available in the `latest` version of AL2023 if we launched a container of the [2023.4.20240319](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.4.20240319.html) release. At the time of writing, the `latest` release is [2023.5.20240708](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.5.20240708.html), so the listed updates in this example will be as of that release. 

**Note**  
 This example uses the [2023.4.20240319](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.4.20240319.html) and [2023.5.20240708](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.5.20240708.html) releases, the latter being the latest release *at the time of writing*. For more information on the latest releases, see the [AL2023 Release Notes](https://docs.aws.amazon.com/linux/al2023/release-notes/). 

 In this example we will be starting with a container image for the [2023.4.20240319](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.4.20240319.html) release. 

 First, we fetch this container image from the container registry. The `.1` at the end indicates the version of the image for a particular release. While the image version is typically zero, this example uses a release where the image version is one. 

```
$ docker pull public.ecr.aws/amazonlinux/amazonlinux:2023.4.20240319.1
	  2023.4.20240319.1: Pulling from amazonlinux/amazonlinux
6de065fda9a2: Pull complete
Digest: sha256:b4838c4cc9211d966b6ea158dacc9eda7433a16ba94436508c2d9f01f7658b4e
Status: Downloaded newer image for public.ecr.aws/amazonlinux/amazonlinux:2023.4.20240319.1
public.ecr.aws/amazonlinux/amazonlinux:2023.4.20240319.1
```

 We can now spawn a shell inside the container, from which we will check for updates. 

```
$ docker run -it public.ecr.aws/amazonlinux/amazonlinux:2023.4.20240319.1
	  bash-5.2#
```

 The `dnf updateinfo` command is now used to display a summary of what advisories in the latest release are relevant to our installed packages. At the time of writing, [2023.1.20230628](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.1.20230628.html) was the latest release. 

```
$ dnf --releasever=latest updateinfo
Amazon Linux 2023 repository                     76 MB/s |  25 MB     00:00
Last metadata expiration check: 0:00:04 ago on Mon Jul 22 20:59:54 2024.
Updates Information Summary: available
    9 Security notice(s)
        4 Important Security notice(s)
        4 Medium Security notice(s)
        1 Low Security notice(s)
```

 To get a list of the advisories, the `--list` option can be given to `dnf updateinfo`. 

```
$ dnf updateinfo --releasever=latest --list
Last metadata expiration check: 0:00:58 ago on Mon Jul 22 20:59:54 2024.
ALAS2023-2024-581 Low/Sec.       curl-minimal-8.5.0-1.amzn2023.0.3.x86_64
ALAS2023-2024-596 Medium/Sec.    curl-minimal-8.5.0-1.amzn2023.0.4.x86_64
ALAS2023-2024-576 Important/Sec. expat-2.5.0-1.amzn2023.0.4.x86_64
ALAS2023-2024-589 Important/Sec. glibc-2.34-52.amzn2023.0.10.x86_64
ALAS2023-2024-589 Important/Sec. glibc-common-2.34-52.amzn2023.0.10.x86_64
ALAS2023-2024-589 Important/Sec. glibc-minimal-langpack-2.34-52.amzn2023.0.10.x86_64
ALAS2023-2024-586 Medium/Sec.    krb5-libs-1.21-3.amzn2023.0.4.x86_64
ALAS2023-2024-581 Low/Sec.       libcurl-minimal-8.5.0-1.amzn2023.0.3.x86_64
ALAS2023-2024-596 Medium/Sec.    libcurl-minimal-8.5.0-1.amzn2023.0.4.x86_64
ALAS2023-2024-592 Important/Sec. libnghttp2-1.59.0-3.amzn2023.0.1.x86_64
ALAS2023-2024-640 Medium/Sec.    openssl-libs-1:3.0.8-1.amzn2023.0.12.x86_64
ALAS2023-2024-605 Medium/Sec.    python3-3.9.16-1.amzn2023.0.7.x86_64
ALAS2023-2024-616 Important/Sec. python3-3.9.16-1.amzn2023.0.8.x86_64
ALAS2023-2024-605 Medium/Sec.    python3-libs-3.9.16-1.amzn2023.0.7.x86_64
ALAS2023-2024-616 Important/Sec. python3-libs-3.9.16-1.amzn2023.0.8.x86_64
```

------

# Applying security updates in-place
<a name="security-inplace-update"></a>

 For an overview of applying updates, see [Applying security updates using DNF and repository versions](managing-repos-os-updates.md#apply-security-updates). The `--security` option to `dnf upgrade` will restrict package updates to only those which have an Advisory. The remainder of this section will cover how to install only specific security updates. 

**Note**  
 It is recommended to apply *all* updates available in a new AL2023 release. Picking just security updates, or only specific updates should be the exception rather than rule. 

## Applying updates mentioned in an Advisory
<a name="applying-advisory-updates"></a>

 The advisory identifiers in the first column of the output of `dnf upgradeinfo` can be used to apply updates for the packages mentioned in the advisory. The `dnf` package manager can be instructed to update the packages in the advisory to either the latest available, or only up to the versions mentioned in the advisory. If the updates are already installed, the update command is a no-op. 

 To apply the updates for affected packages *only up to the version mention in the advisory*, use the `dnf upgrade-minimal` command while using the `--advisory` option to specify the advisory. The following example is running `dnf upgrade-minimal` in an AL2023 version [2023.0.20230315](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.0.20230315.html) container. 

```
$ dnf upgrade-minimal -y --releasever=2023.1.20230628 --advisory ALAS2023-2023-193
Amazon Linux 2023 repository                     46 MB/s |  15 MB     00:00
Last metadata expiration check: 0:00:03 ago on Mon Jul 22 20:36:13 2024.
Dependencies resolved.
================================================================================
 Package              Arch        Version                Repository        Size
================================================================================
Upgrading:
 curl-minimal         x86_64      8.0.1-1.amzn2023       amazonlinux      150 k
 libcurl-minimal      x86_64      8.0.1-1.amzn2023       amazonlinux      249 k

Transaction Summary
================================================================================
Upgrade  2 Packages

Total download size: 399 k
Downloading Packages:
(1/2): curl-minimal-8.0.1-1.amzn2023.x86_64.rpm 2.7 MB/s | 150 kB     00:00
(2/2): libcurl-minimal-8.0.1-1.amzn2023.x86_64. 3.8 MB/s | 249 kB     00:00
--------------------------------------------------------------------------------
Total                                           2.5 MB/s | 399 kB     00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                        1/1
  Upgrading        : libcurl-minimal-8.0.1-1.amzn2023.x86_64                1/4
  Upgrading        : curl-minimal-8.0.1-1.amzn2023.x86_64                   2/4
  Cleanup          : curl-minimal-7.88.1-1.amzn2023.0.1.x86_64              3/4
  Cleanup          : libcurl-minimal-7.88.1-1.amzn2023.0.1.x86_64           4/4
  Running scriptlet: libcurl-minimal-7.88.1-1.amzn2023.0.1.x86_64           4/4
  Verifying        : libcurl-minimal-8.0.1-1.amzn2023.x86_64                1/4
  Verifying        : libcurl-minimal-7.88.1-1.amzn2023.0.1.x86_64           2/4
  Verifying        : curl-minimal-8.0.1-1.amzn2023.x86_64                   3/4
  Verifying        : curl-minimal-7.88.1-1.amzn2023.0.1.x86_64              4/4

Upgraded:
  curl-minimal-8.0.1-1.amzn2023.x86_64  libcurl-minimal-8.0.1-1.amzn2023.x86_64

Complete!
```

 The same package versions are updated even if `--releasever=latest` is used as the request is for `dnf` to do the *minimal update required* to address the advisory. 

 Using the regular `dnf upgrade` command with the `--advisory` option will update the relevant packages mentioned in the advisory to the *latest* version available, which may be newer than the version mentioned in the advisory. 

**Note**  
 Unless the `system-release` package is updated, the version of the AL2023 repositories which `dnf` is locked to *does not change*. 

**Warning**  
 When installing updates from a different release of AL2023 without changing the version of the repository that `dnf` is locked to, care *must* be taken on any subsequent mutating `dnf` operations. For example, when installing or updating packages, since package dependencies may have changed in the newer release, the older release that you remain on may not be able to satisfy these new dependencies. 

 The following example is run in an AL2023 version [2023.0.20230315](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.0.20230315.html) container referring to the latest release of AL2023 which the time of writing was [2023.5.20240708](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.5.20240708.html). Note that both the version of `curl` being updated to is newer than the version `update-minimal` updated to, but that this newer version brings in new dependencies. 

```
$ dnf upgrade -y --releasever=latest --advisory ALAS2023-2023-193
Amazon Linux 2023 repository                     80 MB/s |  25 MB     00:00
Last metadata expiration check: 0:00:04 ago on Mon Jul 22 20:48:38 2024.
Dependencies resolved.
================================================================================
 Package                   Arch     Version                 Repository     Size
================================================================================
Upgrading:
 curl-minimal              x86_64   8.5.0-1.amzn2023.0.4    amazonlinux   160 k
 libcurl-minimal           x86_64   8.5.0-1.amzn2023.0.4    amazonlinux   275 k
 libnghttp2                x86_64   1.59.0-3.amzn2023.0.1   amazonlinux    79 k
Installing dependencies:
 libpsl                    x86_64   0.21.1-3.amzn2023.0.2   amazonlinux    61 k
 publicsuffix-list-dafsa   noarch   20240212-61.amzn2023    amazonlinux    59 k

Transaction Summary
================================================================================
Install  2 Packages
Upgrade  3 Packages

Total download size: 634 k
Downloading Packages:
(1/5): publicsuffix-list-dafsa-20240212-61.amzn 1.1 MB/s |  59 kB     00:00
(2/5): curl-minimal-8.5.0-1.amzn2023.0.4.x86_64 2.6 MB/s | 160 kB     00:00
(3/5): libpsl-0.21.1-3.amzn2023.0.2.x86_64.rpm  949 kB/s |  61 kB     00:00
(4/5): libnghttp2-1.59.0-3.amzn2023.0.1.x86_64. 3.7 MB/s |  79 kB     00:00
(5/5): libcurl-minimal-8.5.0-1.amzn2023.0.4.x86 6.7 MB/s | 275 kB     00:00
--------------------------------------------------------------------------------
Total                                           3.5 MB/s | 634 kB     00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                        1/1
  Upgrading        : libnghttp2-1.59.0-3.amzn2023.0.1.x86_64                1/8
  Installing       : publicsuffix-list-dafsa-20240212-61.amzn2023.noarch    2/8
  Installing       : libpsl-0.21.1-3.amzn2023.0.2.x86_64                    3/8
  Upgrading        : libcurl-minimal-8.5.0-1.amzn2023.0.4.x86_64            4/8
  Upgrading        : curl-minimal-8.5.0-1.amzn2023.0.4.x86_64               5/8
  Cleanup          : curl-minimal-7.88.1-1.amzn2023.0.1.x86_64              6/8
  Cleanup          : libcurl-minimal-7.88.1-1.amzn2023.0.1.x86_64           7/8
  Cleanup          : libnghttp2-1.51.0-1.amzn2023.x86_64                    8/8
  Running scriptlet: libnghttp2-1.51.0-1.amzn2023.x86_64                    8/8
  Verifying        : libpsl-0.21.1-3.amzn2023.0.2.x86_64                    1/8
  Verifying        : publicsuffix-list-dafsa-20240212-61.amzn2023.noarch    2/8
  Verifying        : curl-minimal-8.5.0-1.amzn2023.0.4.x86_64               3/8
  Verifying        : curl-minimal-7.88.1-1.amzn2023.0.1.x86_64              4/8
  Verifying        : libcurl-minimal-8.5.0-1.amzn2023.0.4.x86_64            5/8
  Verifying        : libcurl-minimal-7.88.1-1.amzn2023.0.1.x86_64           6/8
  Verifying        : libnghttp2-1.59.0-3.amzn2023.0.1.x86_64                7/8
  Verifying        : libnghttp2-1.51.0-1.amzn2023.x86_64                    8/8

Upgraded:
  curl-minimal-8.5.0-1.amzn2023.0.4.x86_64
  libcurl-minimal-8.5.0-1.amzn2023.0.4.x86_64
  libnghttp2-1.59.0-3.amzn2023.0.1.x86_64
Installed:
  libpsl-0.21.1-3.amzn2023.0.2.x86_64
  publicsuffix-list-dafsa-20240212-61.amzn2023.noarch

Complete!
```

# Setting SELinux modes for AL2023
<a name="selinux-modes"></a>

By default, Security Enhanced Linux (SELinux) is `enabled` and set to `permissive` mode for AL2023. In permissive mode, permission denials are logged but not enforced. SELinux is a collection of kernel features and utilities to provide a strong, flexible, mandatory access control (MAC) architecture to the major subsystems of the kernel. 

SELinux provides an enhanced mechanism to enforce the separation of information based on confidentiality and integrity requirements. This separation of information reduces threats of tampering and bypassing of application security mechanisms. It also confines damage that can be caused by malicious or flawed applications. 

SELinux includes a set of sample security policy configuration files that's designed to meet everyday security goals.

For more information about SELinux features and functionality, see [SELinux Notebook](https://github.com/SELinuxProject/selinux-notebook/blob/main/src/toc.md) and [Policy Languages"](https://github.com/SELinuxProject/selinux-notebook/blob/main/src/policy_languages.md). 

**Topics**
+ [Default SELinux status and modes for AL2023](default-SELinux-modes-states.md)
+ [Change to `enforcing` mode](enforcing-mode.md)
+ [Option to disable SELinux for AL2023](disable-option-selinux.md)

# Default SELinux status and modes for AL2023
<a name="default-SELinux-modes-states"></a>

For AL2023, SELinux by default is `enabled` and set to `permissive` mode. In `permissive` mode, permission denials are logged but not enforced.

The **getenforce** or **sestatus** commands tell you the current SELinux status, policy, and mode. 

With the default status set to `enabled` and `permissive`, the **getenforce** command returns `permissive`. 

The **sestatus** command returns the SELinux status and the current SELinux policy as shown in the following example: 

```
$ sestatus
SELinux status:                 enabled
  SELinuxfs mount:                /sys/fs/selinux
  SELinux root directory:         /etc/selinux
  Loaded policy name:             targeted
  Current mode:                   permissive
  Mode from config file:          permissive
  Policy MLS status:              enabled
  Policy deny_unknown status:     allowed
  Memory protection checking:     actual (secure)
  Max kernel policy version:      33
```

When you run SELinux in `permissive` mode, users might label files incorrectly. When you run SELinux in the `disabled` status, files aren't labeled. Both incorrect or unlabeled files can cause problems when you change to `enforcing` mode.

SELinux automatically relabels files to avoid this problem. SELinux prevents labeling problems with automatic relabeling when you change the status to `enabled`.

# Change to `enforcing` mode
<a name="enforcing-mode"></a>

When you run SELinux in `enforcing` mode, the SELinux utility is `enforcing` the configured policy. SELinux governs the capabilities of select applications by allowing or denying access based on the policy’s rules.

To find the current SELinux mode, run the `getenforce` command.

```
getenforce
Permissive
```

## Edit config file to enable `enforcing` mode
<a name="config-file-enforcing"></a>

To change the mode to `enforcing`, use the following steps.

1. Edit the `/etc/selinux/config` file to change to `enforcing` mode. The `SELINUX` setting should look like the following example.

   ```
   SELINUX=enforcing
   ```

1. Restart your system to complete the change to `enforcing` mode.

   ```
   $ sudo reboot
   ```

On the next boot, SELinux relabels all files and directories in the system. SELinux also adds the SELinux context for files and directories that were created when SELinux was `disabled`.

After changing to `enforcing` mode, SELinux might deny some actions because of incorrect or missing SELinux policy rules. You can view the actions that SELinux denies with the following command.

```
$ sudo ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent
```

## Use cloud-init to enable `enforcing` mode
<a name="cloud-init-enforcing"></a>

As an alternative, when you launch your instance, pass the following `cloud-config` as user-data to enable `enforcing` mode. 

```
#cloud-config
selinux: 
  mode: enforcing
```

By default, this setting causes the instance to reboot. For greater stability, we recommend rebooting your instance. However, if you prefer, you can skip the reboot by providing the following `cloud-config`.

```
#cloud-config
selinux:
  mode: enforcing
  selinux_no_reboot: 1
```

# Option to disable SELinux for AL2023
<a name="disable-option-selinux"></a>

When you disable SELinux, SELinux policy isn't loaded or enforced and Access Vector Cache (AVC) messages aren't logged. You lose all benefits of running SELinux. 

Instead of disabling SELinux, we recommend using `permissive` mode. It costs only a little more to run in `permissive` mode than it does to disable SELinux completely. Transitioning from `permissive` mode to `enforcing` mode requires much less of a configuration adjustment than transitioning back to `enforcing` mode after disabling SELinux. You can label files, and the system can track and log actions that the active policy might have denied. 

## Change SELinux to `permissive` mode
<a name="change-to-permissive"></a>

When you run SELinux in `permissive` mode, SELinux policy isn’t enforced. In `permissive` mode, SELinux logs AVC messages but doesn’t deny operations. You can use these AVC messages for troubleshooting, debugging, and SELinux policy improvements. 

To change SELinux to permissive mode, use the following steps.

1. Edit the `/etc/selinux/config` file to change to `permissive` mode. The `SELINUX` value should look like the following example.

   ```
   SELINUX=permissive
   ```

1. Restart your system to complete the change to `permissive` mode.

   ```
   sudo reboot
   ```

## Disable SELinux
<a name="disable-selinux"></a>

When you disable SELinux, SELinux policy isn't loaded or enforced, and AVC messages aren't logged. You lose all benefits of running SELinux.

To disable SELinux, use the following steps.

1. Ensure that the `grubby` package is installed.

   ```
   rpm -q grubby
   grubby-version
   ```

1. Configure your bootloader to add `selinux=0` to the kernel command line.

   ```
   sudo grubby --update-kernel ALL --args selinux=0
   ```

1. Restart your system.

   ```
   sudo reboot
   ```

1. Run the `getenforce ` command to confirm that SELinux is `Disabled`.

   ```
   $ getenforce
   Disabled
   ```

For more information about SELinux, see the [SELinux Notebook](https://github.com/SELinuxProject/selinux-notebook/blob/main/src/toc.md) and [SELinux configuration](http://selinuxproject.org/page/Guide/Mode#SELinux_Config).

# Enable FIPS Mode on AL2023
<a name="fips-mode"></a>

This section explains how to enable Federal Information Processing Standards (FIPS) on AL2023. For more information about FIPS, see:
+ [Federal Information Processing Standard (FIPS)](https://aws.amazon.com/compliance/fips/)
+ [Compliance FAQs: Federal Information Processing Standards](https://www.nist.gov/standardsgov/compliance-faqs-federal-information-processing-standards-fips)

**Note**  
This section documents how to enable FIPS mode in AL2023, it doesn't cover the certification status of AL2023 cryptographic modules.

**Prerequisites**
+ An existing AL2023 (AL2023.2 or higher) Amazon EC2 instance with access to the internet to download required packages. For more information about launching an AL2023 Amazon EC2 instance, see [Launching AL2023 using the Amazon EC2 console](ec2.md#launch-from-ec2-console).
+ You must connect to your Amazon EC2 instance using SSH or AWS Systems Manager. For more information, see [Connecting to AL2023 instances](connecting-to-instances.md).

**Important**  
ED25519 SSH user keys aren't supported in FIPS mode. If you launched your Amazon EC2 instance using an ED25519 SSH key pair, you must generate new keys using another algorithm (such as RSA) or you may lose access to your instance after enabling FIPS mode. For more information see [Create key pairs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-key-pairs.html) in the *Amazon EC2 User Guide*.

**Enable FIPS Mode**

1. Connect to your AL2023 instance using SSH or AWS Systems Manager.

1. Ensure the system is up to date. For more information, see [Manage package and operating system updates in AL2023](managing-repos-os-updates.md).

1. Ensure the `crypto-policies` utilities are installed and up-to-date.

   ```
   sudo dnf -y install crypto-policies crypto-policies-scripts
   ```

1. Enable FIPS mode by running the following command. This will enable FIPS mode system-wide for the modules listed in the [AL2023 FAQ](https://aws.amazon.com/linux/amazon-linux-2023/faqs/) 

   ```
   sudo fips-mode-setup --enable
   ```

1. Reboot the instance using the following command.

   ```
   sudo reboot
   ```

1. To verify that FIPS mode is enabled, reconnect to your instance and run the following command.

   ```
   sudo fips-mode-setup --check
   ```

   The following example output shows FIPS mode is enabled:

   ```
   FIPS mode is enabled.
   ```

# Enable FIPS Mode in an AL2023 Container
<a name="fips-mode-container"></a>

This section explains how to enable Federal Information Processing Standards (FIPS) in an AL2023 container. For more information about FIPS, see:
+ [Federal Information Processing Standard (FIPS)](https://aws.amazon.com/compliance/fips/)
+ [Compliance FAQs: Federal Information Processing Standards](https://www.nist.gov/standardsgov/compliance-faqs-federal-information-processing-standards-fips)

**Note**  
This section documents how to enable FIPS mode in an AL2023 container. It does not cover the certification status of AL2023 cryptographic modules.

**Prerequisites**
+ An existing AL2023 (AL2023.2 or higher) Amazon EC2 instance with access to the internet to download required packages. For more information about launching an AL2023 Amazon EC2 instance, see [Launching AL2023 using the Amazon EC2 console](ec2.md#launch-from-ec2-console).
+ You must connect to your Amazon EC2 instance using SSH or AWS Systems Manager. For more information, see [Connecting to AL2023 instances](connecting-to-instances.md).

**Important**  
The `fips-mode-setup` command will not work correctly from within the container. Please read the steps below to properly configure FIPS mode in an AL2023 container.

**Enable FIPS Mode in an AL2023 Container**

1. FIPS mode must first be enabled on the AL2023 container Host. Follow the instructions at [Enable FIPS Mode on AL2023](fips-mode.md) to enable FIPS mode on the Host.

1. Connect to your AL2023 container host instance using SSH or AWS Systems Manager.

1. FIPS mode will be automatically enabled in an AL2023 container if the AL2023 host is in FIPS mode and `/proc/sys/crypto/fips_enabled` is accessible from within the container. If the contents of `/proc/sys/crypto/fips_enabled` is `0` then FIPS is not enabled, and a value of `1` indicates that FIPS mode is enabled.

   You can verify that FIPS is enabled by running the following command on both the AL2023 host and container:

   ```
   cat /proc/sys/crypto/fips_enabled
   ```

1. Next, enable the FIPS crypto-policies within the container. There are several ways to accomplish this, described in the options below. Use the option that works best for your environment.

   1. Enable the FIPS crypto-policies manually within the container using the `update-crypto-policies` command:

      ```
      # Run these commands inside the container
      dnf install -y crypto-policies-scripts
      update-crypto-policies --set FIPS
      ```

   1. Create `bind` mounts within the AL2023 container (this is similar to how `podman` works in other distributions):

      ```
      # Run these commands inside the container
      mount --bind /usr/share/crypto-policies/back-ends/FIPS /etc/crypto-policies/back-ends
      echo "FIPS" > /usr/share/crypto-policies/default-fips-config
      mount --bind /usr/share/crypto-policies/default-fips-config /etc/crypto-policies/config
      ```

   1. It is also possible to create a bind mount so that the AL2023 container matches the AL2023 host's crypto-policies. The following is only provided as an example. This configuration could cause issues if there are incompatible differences in the crypto-policies and package versions between the container and host:

      ```
      sudo docker pull amazonlinux:2023
      sudo docker run --mount type=bind,readonly,src=/etc/crypto-policies,dst=/etc/crypto-policies -it amazonlinux:2023
      ```

1. After performing the steps above you can again verify that FIPS is enabled in the container with the following commands:

   ```
   $ cat /etc/crypto-policies/config
   FIPS
   
   $ cat /proc/sys/crypto/fips_enabled
   1
   ```

# Swap OpenSSL FIPS providers on AL2023
<a name="fips-openssl-swap-provider"></a>

This section explains how to switch between the `latest` and `certified` OpenSSL FIPS providers on AL2023.

For more information about FIPS, see:
+ [Federal Information Processing Standard (FIPS)](https://aws.amazon.com/compliance/fips/)
+ [Compliance FAQs: Federal Information Processing Standards](https://www.nist.gov/standardsgov/compliance-faqs-federal-information-processing-standards-fips)
+ [FedRAMP Policy for Cryptographic Module Selection and Use](https://www.fedramp.gov/rev5/fips/)

**Important**  
On AL2023.7 and higher, the default OpenSSL FIPS provider is the `openssl-fips-provider-latest` package, which receives regular bugfix and security updates.  
The instructions below are only for customers who want to pin to the `openssl-fips-provider-certified` package. This version of the FIPS provider will match the checksum on the NIST certificate, and may not have the latest updates.  
See the [AL2023 FAQ](https://aws.amazon.com/linux/amazon-linux-2023/faqs/) for more information about FIPS certified modules and package versions.

**Prerequisites**
+ An existing AL2023 (AL2023.7 or higher) Amazon EC2 instance with access to the internet to download required packages. For more information about launching an AL2023 Amazon EC2 instance, see [Launching AL2023 using the Amazon EC2 console](ec2.md#launch-from-ec2-console).
+ You must connect to your Amazon EC2 instance using SSH or AWS Systems Manager. For more information, see [Connecting to AL2023 instances](connecting-to-instances.md).
+ To enable FIPS mode on AL2023, follow the instructions at [Enable FIPS Mode on AL2023](fips-mode.md).

**Switch between `openssl-fips-provider-latest` and `openssl-fips-provider-certified`**

1. Use `dnf` to switch the OpenSSL FIPS provider:

   ```
   sudo dnf -y swap openssl-fips-provider-latest openssl-fips-provider-certified
   ```

1. Check that you are using the certified OpenSSL FIPS provider. With AL2023 in FIPS mode, run the following command:

   ```
   openssl list -providers
   ```

   You should see the following output:

   ```
   Providers:
     base
       name: OpenSSL Base Provider
       version: 3.2.2
       status: active
     default
       name: OpenSSL Default Provider
       version: 3.2.2
       status: active
     fips
       name: Amazon Linux 2023 - OpenSSL FIPS Provider
       version: 3.0.8-d694bfa693b76001
       status: active
   ```

# AL2023 Kernel Hardening
<a name="kernel-hardening"></a>

 The 6.1 Linux kernel in AL2023 is configured and built with several hardening options and features. 

## Kernel Hardening options (architecture independent)
<a name="kernel-hardening-common"></a>


| `CONFIG` option | AL2023/6.1/aarch64 | AL2023/6.1/x86\$164 | AL2023/6.12/aarch64 | AL2023/6.12/x86\$164 | AL2023/6.18/aarch64 | AL2023/6.18/x86\$164 | 
| --- | --- | --- | --- | --- | --- | --- | 
|  [`CONFIG_ACPI_CUSTOM_METHOD`](#CONFIG_ACPI_CUSTOM_METHOD)  |  n  |  n  | N/A | N/A | N/A | N/A | 
|  [`CONFIG_BINFMT_MISC`](#CONFIG_BINFMT_MISC)  |  m  |  m  |  m  |  m  |  m  |  m  | 
|  [`CONFIG_BUG`](#CONFIG_BUG)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_BUG_ON_DATA_CORRUPTION`](#CONFIG_BUG_ON_DATA_CORRUPTION)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_CFI_CLANG`](#CONFIG_CFI_CLANG)  | N/A | N/A | N/A | N/A | N/A | N/A | 
|  [`CONFIG_CFI_PERMISSIVE`](#CONFIG_CFI_PERMISSIVE)  | N/A | N/A | N/A | N/A | N/A | N/A | 
|  [`CONFIG_COMPAT`](#CONFIG_COMPAT)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_COMPAT_BRK`](#CONFIG_COMPAT_BRK)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_COMPAT_VDSO`](#CONFIG_COMPAT_VDSO)  | N/A |  n  | N/A |  n  | N/A |  n  | 
|  [`CONFIG_DEBUG_CREDENTIALS`](#CONFIG_DEBUG_CREDENTIALS)  |  n  |  n  | N/A | N/A | N/A | N/A | 
|  [`CONFIG_DEBUG_LIST`](#CONFIG_DEBUG_LIST)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_DEBUG_NOTIFIERS`](#CONFIG_DEBUG_NOTIFIERS)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_DEBUG_SG`](#CONFIG_DEBUG_SG)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_DEBUG_VIRTUAL`](#CONFIG_DEBUG_VIRTUAL)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_DEBUG_WX`](#CONFIG_DEBUG_WX)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_DEFAULT_MMAP_MIN_ADDR`](#CONFIG_DEFAULT_MMAP_MIN_ADDR)  |  65536  |  65536  |  65536  |  65536  |  65536  |  65536  | 
|  [`CONFIG_DEVKMEM`](compare-with-al2-kernel.md#CONFIG_DEVKMEM)  | N/A | N/A | N/A | N/A | N/A | N/A | 
|  [`CONFIG_DEVMEM`](compare-with-al2-kernel.md#CONFIG_DEVMEM)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_EFI_DISABLE_PCI_DMA`](#CONFIG_EFI_DISABLE_PCI_DMA)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_FORTIFY_SOURCE`](compare-with-al2-kernel.md#CONFIG_FORTIFY_SOURCE)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_HARDENED_USERCOPY`](#CONFIG_HARDENED_USERCOPY)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_HARDENED_USERCOPY_FALLBACK`](#CONFIG_HARDENED_USERCOPY_FALLBACK)  | N/A | N/A | N/A | N/A | N/A | N/A | 
|  [`CONFIG_HARDENED_USERCOPY_PAGESPAN`](#CONFIG_HARDENED_USERCOPY_PAGESPAN)  | N/A | N/A | N/A | N/A | N/A | N/A | 
|  [`CONFIG_HIBERNATION`](#CONFIG_HIBERNATION)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_HW_RANDOM_TPM`](#CONFIG_HW_RANDOM_TPM)  | N/A | N/A | N/A | N/A | N/A | N/A | 
|  [`CONFIG_INET_DIAG`](#CONFIG_INET_DIAG)  |  m  |  m  |  m  |  m  |  m  |  m  | 
|  [`CONFIG_INIT_ON_ALLOC_DEFAULT_ON`](#CONFIG_INIT_ON_ALLOC_DEFAULT_ON)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_INIT_ON_FREE_DEFAULT_ON`](#CONFIG_INIT_ON_FREE_DEFAULT_ON)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_INIT_STACK_ALL_ZERO`](#CONFIG_INIT_STACK_ALL_ZERO)  | N/A | N/A | N/A | N/A | N/A | N/A | 
|  [`CONFIG_IOMMU_DEFAULT_DMA_STRICT`](#CONFIG_IOMMU_DEFAULT_DMA_STRICT)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_IOMMU_SUPPORT`](#CONFIG_IOMMU_SUPPORT)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_IO_STRICT_DEVMEM`](compare-with-al2-kernel.md#CONFIG_IO_STRICT_DEVMEM)  | N/A | N/A | N/A | N/A | N/A | N/A | 
|  [`CONFIG_KEXEC`](#CONFIG_KEXEC)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_KFENCE`](#CONFIG_KFENCE)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_LDISC_AUTOLOAD`](compare-with-al2-kernel.md#CONFIG_LDISC_AUTOLOAD)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_LEGACY_PTYS`](#CONFIG_LEGACY_PTYS)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY`](#CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_MODULES`](#CONFIG_MODULES)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_MODULE_SIG`](#CONFIG_MODULE_SIG)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_MODULE_SIG_ALL`](#CONFIG_MODULE_SIG_ALL)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_MODULE_SIG_FORCE`](#CONFIG_MODULE_SIG_FORCE)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_MODULE_SIG_HASH`](#CONFIG_MODULE_SIG_HASH)  |  sha512  |  sha512  |  sha512  |  sha512  |  sha512  |  sha512  | 
|  [`CONFIG_MODULE_SIG_KEY`](#CONFIG_MODULE_SIG_KEY)  |  certs/signing\$1key.pem  |  certs/signing\$1key.pem  |  certs/signing\$1key.pem  |  certs/signing\$1key.pem  |  certs/signing\$1key.pem  |  certs/signing\$1key.pem  | 
|  [`CONFIG_MODULE_SIG_SHA512`](#CONFIG_MODULE_SIG_SHA512)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_PAGE_POISONING`](#CONFIG_PAGE_POISONING)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_PAGE_POISONING_NO_SANITY`](#CONFIG_PAGE_POISONING_NO_SANITY)  | N/A | N/A | N/A | N/A | N/A | N/A | 
|  [`CONFIG_PAGE_POISONING_ZERO`](#CONFIG_PAGE_POISONING_ZERO)  | N/A | N/A | N/A | N/A | N/A | N/A | 
|  [`CONFIG_PANIC_ON_OOPS`](compare-with-al2-kernel.md#CONFIG_PANIC_ON_OOPS)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_PANIC_TIMEOUT`](#CONFIG_PANIC_TIMEOUT)  |  0  |  0  |  0  |  0  |  0  |  0  | 
|  [`CONFIG_PROC_KCORE`](#CONFIG_PROC_KCORE)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT`](#CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_RANDOM_TRUST_BOOTLOADER`](#CONFIG_RANDOM_TRUST_BOOTLOADER)  |  y  |  y  | N/A | N/A | N/A | N/A | 
|  [`CONFIG_RANDOM_TRUST_CPU`](#CONFIG_RANDOM_TRUST_CPU)  |  y  |  y  | N/A | N/A | N/A | N/A | 
|  [`CONFIG_REFCOUNT_FULL`](#CONFIG_REFCOUNT_FULL)  | N/A | N/A | N/A | N/A | N/A | N/A | 
|  [`CONFIG_SCHED_CORE`](#CONFIG_SCHED_CORE)  | N/A |  y  | N/A |  y  | N/A |  y  | 
|  [`CONFIG_SCHED_STACK_END_CHECK`](#CONFIG_SCHED_STACK_END_CHECK)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_SECCOMP`](#CONFIG_SECCOMP)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_SECCOMP_FILTER`](#CONFIG_SECCOMP_FILTER)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_SECURITY`](#CONFIG_SECURITY)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_SECURITY_DMESG_RESTRICT`](compare-with-al2-kernel.md#CONFIG_SECURITY_DMESG_RESTRICT)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_SECURITY_LANDLOCK`](#CONFIG_SECURITY_LANDLOCK)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_SECURITY_LOCKDOWN_LSM`](#CONFIG_SECURITY_LOCKDOWN_LSM)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_SECURITY_LOCKDOWN_LSM_EARLY`](#CONFIG_SECURITY_LOCKDOWN_LSM_EARLY)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_SECURITY_SELINUX_BOOTPARAM`](#CONFIG_SECURITY_SELINUX_BOOTPARAM)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_SECURITY_SELINUX_DEVELOP`](#CONFIG_SECURITY_SELINUX_DEVELOP)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_SECURITY_SELINUX_DISABLE`](compare-with-al2-kernel.md#CONFIG_SECURITY_SELINUX_DISABLE)  |  n  |  n  | N/A | N/A | N/A | N/A | 
|  [`CONFIG_SECURITY_WRITABLE_HOOKS`](#CONFIG_SECURITY_WRITABLE_HOOKS)  | N/A | N/A | N/A | N/A | N/A | N/A | 
|  [`CONFIG_SECURITY_YAMA`](#CONFIG_SECURITY_YAMA)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_SHUFFLE_PAGE_ALLOCATOR`](#CONFIG_SHUFFLE_PAGE_ALLOCATOR)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_SLAB_FREELIST_HARDENED`](#CONFIG_SLAB_FREELIST_HARDENED)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_SLAB_FREELIST_RANDOM`](#CONFIG_SLAB_FREELIST_RANDOM)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_SLUB_DEBUG`](#CONFIG_SLUB_DEBUG)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_STACKPROTECTOR`](#CONFIG_STACKPROTECTOR)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_STACKPROTECTOR_STRONG`](#CONFIG_STACKPROTECTOR_STRONG)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_STATIC_USERMODEHELPER`](#CONFIG_STATIC_USERMODEHELPER)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_STRICT_DEVMEM`](compare-with-al2-kernel.md#CONFIG_STRICT_DEVMEM)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_STRICT_KERNEL_RWX`](#CONFIG_STRICT_KERNEL_RWX)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_STRICT_MODULE_RWX`](#CONFIG_STRICT_MODULE_RWX)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_SYN_COOKIES`](#CONFIG_SYN_COOKIES)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_VMAP_STACK`](#CONFIG_VMAP_STACK)  |  y  |  y  |  y  |  y  |  y  |  y  | 
|  [`CONFIG_WERROR`](#CONFIG_WERROR)  |  n  |  n  |  n  |  n  |  n  |  n  | 
|  [`CONFIG_ZERO_CALL_USED_REGS`](#CONFIG_ZERO_CALL_USED_REGS)  |  n  |  n  |  n  |  n  |  n  |  n  | 

### Allow ACPI methods to be inserted/replaced at runtime (CONFIG\$1ACPI\$1CUSTOM\$1METHOD)
<a name="CONFIG_ACPI_CUSTOM_METHOD"></a>

Amazon Linux disables this option as it allows `root` users to write to arbitrary kernel memory.

This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings).

### Miscellaneous Binary Formats (`binfmt_misc`)
<a name="CONFIG_BINFMT_MISC"></a>

 Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. In AL2023, this feature is optional, and is built as a kernel module. 

### `BUG()` support
<a name="CONFIG_BUG"></a>

 This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### `BUG()` if kernel encounters data corruption in when checking kernel memory structures for validity
<a name="CONFIG_BUG_ON_DATA_CORRUPTION"></a>

 Some parts of the Linux kernel will check the internal consistency of data structures and can `BUG()` when they detect data corruption. 

 This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### `COMPAT_BRK`
<a name="CONFIG_COMPAT_BRK"></a>

 With this option disabled (which is how Amazon Linux configures the kernel), the `randomize_va_space` `sysctl` setting defaults to `2`, which also enables heap randomization on top of `mmap` base, stack, and VDSO page randomization. 

 This option exists in the kernel to provide compatibility with some ancient `libc.so.5` binaries from 1996 and earlier. 

 This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### `COMPAT_VDSO`
<a name="CONFIG_COMPAT_VDSO"></a>

 This configuration option is relevant to `x86-64` and not `aarch64`. By setting this to `n`, the Amazon Linux kernel does not make a 32-bit virtual Dynamic Shared Object (VDSO) visible at a predictable address. The most recent `glibc` known to be broken by this option being set to `n` is `glibc` 2.3.3, from 2004. 

 This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### `CONFIG_DEBUG` gated hardening
<a name="CONFIG_DEBUG_KERNEL"></a>

 Linux kernel configuration options gated by `CONFIG_DEBUG` are typically designed for use in kernels built for debugging issues, and things like performance are not a priority. AL2023 enables the `CONFIG_DEBUG_LIST` hardening option. 

### Disable DMA for PCI devices in EFI stub before configuring the IOMMU
<a name="CONFIG_EFI_DISABLE_PCI_DMA"></a>

 Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. 

### Hardening for copying memory between kernel and userspace
<a name="CONFIG_HARDENED_USERCOPY"></a>

 When the kernel needs to copy memory to or from userspace, this option enables some checks which can protect against some classes of heap overflow issues. 

 The `CONFIG_HARDENED_USERCOPY_FALLBACK` option existed in kernels 4.16 through 5.15 to help kernel developers discover any missing allowlist entries via a `WARN()`. Because AL2023 ships a 6.1 kernel, this option is no longer relevant to AL2023. 

 The `CONFIG_HARDENED_USERCOPY_PAGESPAN` option existed in kernels primarily as a debugging option for developers and no longer applies to the 6.1 kernel in AL2023. 

 This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### Hibernation Support
<a name="CONFIG_HIBERNATION"></a>

 Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. This option needs to be enabled in order to support the ability to [Hibernate your On-Demand Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Hibernate.html), and to support the ability to [Hibernate interrupted Spot Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/hibernate-spot-instances.html) 

### Random Number Generation
<a name="kernel-rng"></a>

 The AL2023 kernel is configured to ensure adequate entropy is available for usage within EC2. 

### `CONFIG_INET_DIAG`
<a name="CONFIG_INET_DIAG"></a>

 Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. In AL2023, this feature is optional, and is built as a kernel module. 

### Zero all kernel page and slab allocator memory on allocation and deallocation
<a name="kernel-init-on-alloc-free"></a>

 Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. These options are disabled in AL2023 due to the possible performance impact of enabling this functionality by default. The `CONFIG_INIT_ON_ALLOC_DEFAULT_ON` behavior can be enabled by adding `init_on_alloc=1` to the kernel command line, and the `CONFIG_INIT_ON_FREE_DEFAULT_ON` behavior can be enabled by adding `init_on_free=1`. 

### Initialize all stack variables as zero (`CONFIG_INIT_STACK_ALL_ZERO`)
<a name="CONFIG_INIT_STACK_ALL_ZERO"></a>

 Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. This option requires GCC 12 or higher, while AL2023 ships with GCC 11. 

### Kernel Module Signing
<a name="kernel-config-modules"></a>

 AL2023 signs and validates the signatures of kernel modules. The `CONFIG_MODULE_SIG_FORCE` option, which would require modules to have a valid signature is not enabled in order to preserve compatibility for users building third party modules. For users wanting to ensure that all kernel modules are signed, the [  Lockdown Linux Security Module (LSM)](#CONFIG_SECURITY_LOCKDOWN_LSM) can be configured to enforce this. 

### `kexec`
<a name="CONFIG_KEXEC"></a>

 Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. This option is enabled so that `kdump` functionality can be used. 

### `IOMMU` Support
<a name="CONFIG_IOMMU_SUPPORT"></a>

 AL2023 enables IOMMU support. The `CONFIG_IOMMU_DEFAULT_DMA_STRICT` option is not enabled by default, but this functionality can be configured by adding `iommu.passthrough=0 iommu.strict=1` to the kernel command line. 

### `kfence`
<a name="CONFIG_KFENCE"></a>

 Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. 

### Legacy `pty` Support
<a name="CONFIG_LEGACY_PTYS"></a>

 AL2023 uses the modern PTY interface (`devpts`). 

 This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### Lockdown Linux Security Module (LSM)
<a name="CONFIG_SECURITY_LOCKDOWN_LSM"></a>

 AL2023 builds the `lockdown` LSM, which will automatically lock down the kernel when using Secure Boot. 

 The `CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY` option is not enabled. Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. When not using Secure Boot, it is possible to enable the lockdown LSM and configure as wanted. 

### Page Poisoning
<a name="CONFIG_PAGE_POISONING"></a>

 Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. Similarly to [  Zero all kernel page and slab allocator memory on allocation and deallocation](#kernel-init-on-alloc-free), this is disabled in the AL2023 kernel due to the possible impact on performance. 

### Stack Protector
<a name="CONFIG_STACKPROTECTOR"></a>

 The AL2023 kernel is built with the stack-protector feature of GCC enabled with the `-fstack-protector-strong` option. 

 This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### seccomp BPF API
<a name="CONFIG_SECCOMP"></a>

 The seccomp hardening feature is used by software such as `systemd` and container runtimes to harden userspace applications. 

 This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### `panic()` timeout
<a name="CONFIG_PANIC_TIMEOUT"></a>

 The AL2023 kernel is configured with this value set to `0`, meaning that the kernel will not reboot after it panics. Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. This is configurable through `sysctl`, `/proc/sys/kernel/panic`, and on the kernel command line. 

### Security Models
<a name="CONFIG_SECURITY"></a>

 AL2023 enables SELinux in Permissive mode by default. For more information, see [Setting SELinux modes for AL2023](selinux-modes.md). 

 The [  Lockdown Linux Security Module (LSM)](#CONFIG_SECURITY_LOCKDOWN_LSM) and `yama` modules are also enabled. 

### `/proc/kcore`
<a name="CONFIG_PROC_KCORE"></a>

 Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. 

### Kernel stack offset randomization on syscall entry
<a name="CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT"></a>

 Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. This can be enabled by setting `randomize_kstack_offset=on` on the kernel command line. 

### Reference counting checks (`CONFIG_REFCOUNT_FULL`)
<a name="CONFIG_REFCOUNT_FULL"></a>

 Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. This option is not curretly enabled due to its possible impact on performance. 

### Scheduler awareness of SMT cores (`CONFIG_SCHED_CORE`)
<a name="CONFIG_SCHED_CORE"></a>

 The AL2023 kernel is built with `CONFIG_SCHED_CORE`, which enables userspace applications to use `prctl(PR_SCHED_CORE)`. This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### Check for stack corruption on calls to `schedule()` (`CONFIG_SCHED_STACK_END_CHECK`)
<a name="CONFIG_SCHED_STACK_END_CHECK"></a>

 The AL2023 kernel is built with `CONFIG_SCHED_STACK_END_CHECK` enabled. This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### Memory allocator hardening
<a name="kernel-allocator-hardening"></a>

 The AL2023 kernel enables hardening of the kernel memory allocator with the `CONFIG_SHUFFLE_PAGE_ALLOCATOR`, `CONFIG_SLAB_FREELIST_HARDENED`, and `CONFIG_SLAB_FREELIST_RANDOM` options. This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### SLUB debugging support
<a name="CONFIG_SLUB_DEBUG"></a>

 The AL2023 kernel enables `CONFIG_SLUB_DEBUG` as this option enables optional debugging features for the allocator that can be enabled on the kernel command line. This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### CONFIG\$1STATIC\$1USERMODEHELPER
<a name="CONFIG_STATIC_USERMODEHELPER"></a>

 Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. This is because `CONFIG_STATIC_USERMODEHELPER` requires special support from the distribution, which is not currently present in Amazon Linux. 

### Read-Only kernel text and rodata (`CONFIG_STRICT_KERNEL_RWX` and `CONFIG_STRICT_MODULE_RWX`)
<a name="CONFIG_STRICT_KERNEL_RWX"></a>

 The AL2023 kernel is configured to mark kernel and kernel module text and rodata memory as read-only, and non-text memory marked as not executable. This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### TCP syncookie support (`CONFIG_SYN_COOKIES`)
<a name="CONFIG_SYN_COOKIES"></a>

 The AL2023 kernel is built with support for TCP syncookies. This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### Virtually mapped stack with guard pages (`CONFIG_VMAP_STACK`)
<a name="CONFIG_VMAP_STACK"></a>

 The AL2023 kernel is built with `CONFIG_VMAP_STACK`, enabling virtually mapped kernel stacks with guard pages. This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### Build with compiler warnings as errors (`CONFIG_WERROR`)
<a name="CONFIG_WERROR"></a>

 Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. 

### Register zeroing on function exit (`CONFIG_ZERO_CALL_USED_REGS`)
<a name="CONFIG_ZERO_CALL_USED_REGS"></a>

 Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. 

### Minimum address for userspace allocation
<a name="CONFIG_DEFAULT_MMAP_MIN_ADDR"></a>

 This hardening option can help reduce the impact of kernel NULL pointer bugs. This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### `clang` specific hardening options
<a name="kernel-hardening-clang"></a>

 The AL2023 kernel is built with GCC rather than clang, so the `CONFIG_CFI_CLANG` hardening option cannot be enabled, which also makes `CONFIG_CFI_PERMISSIVE` not applicable. Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. 

## x86-64 specific Kernel Hardening options
<a name="kernel-hardening-x86-64"></a>


| `CONFIG` option | AL2023/6.1/aarch64 | AL2023/6.1/x86\$164 | AL2023/6.12/aarch64 | AL2023/6.12/x86\$164 | AL2023/6.18/aarch64 | AL2023/6.18/x86\$164 | 
| --- | --- | --- | --- | --- | --- | --- | 
|  [`CONFIG_AMD_IOMMU`](#CONFIG_AMD_IOMMU)  | N/A |  y  | N/A |  y  | N/A |  y  | 
|  [`CONFIG_AMD_IOMMU_V2`](#CONFIG_AMD_IOMMU_V2)  | N/A |  y  | N/A | N/A | N/A | N/A | 
|  [`CONFIG_IA32_EMULATION`](#CONFIG_IA32_EMULATION)  | N/A |  y  | N/A |  y  | N/A |  y  | 
|  [`CONFIG_INTEL_IOMMU`](#CONFIG_INTEL_IOMMU)  | N/A |  y  | N/A |  y  | N/A |  y  | 
|  [`CONFIG_INTEL_IOMMU_DEFAULT_ON`](#CONFIG_INTEL_IOMMU_DEFAULT_ON)  | N/A |  n  | N/A |  n  | N/A |  n  | 
|  [`CONFIG_INTEL_IOMMU_SVM`](#CONFIG_INTEL_IOMMU_SVM)  | N/A |  n  | N/A |  n  | N/A |  n  | 
|  [`CONFIG_LEGACY_VSYSCALL_NONE`](#CONFIG_LEGACY_VSYSCALL_NONE)  | N/A |  n  | N/A |  n  | N/A |  n  | 
|  [`CONFIG_MODIFY_LDT_SYSCALL`](#CONFIG_MODIFY_LDT_SYSCALL)  | N/A |  n  | N/A |  n  | N/A |  n  | 
|  [`CONFIG_PAGE_TABLE_ISOLATION`](#CONFIG_PAGE_TABLE_ISOLATION)  | N/A |  y  | N/A | N/A | N/A | N/A | 
|  [`CONFIG_RANDOMIZE_MEMORY`](#CONFIG_RANDOMIZE_MEMORY)  | N/A |  y  | N/A |  y  | N/A |  y  | 
|  [`CONFIG_X86_64`](#CONFIG_X86_64)  | N/A |  y  | N/A |  y  | N/A |  y  | 
|  [`CONFIG_X86_MSR`](#CONFIG_X86_MSR)  | N/A |  y  | N/A |  y  | N/A |  y  | 
|  [`CONFIG_X86_VSYSCALL_EMULATION`](#CONFIG_X86_VSYSCALL_EMULATION)  | N/A |  y  | N/A |  y  | N/A |  y  | 
|  [`CONFIG_X86_X32`](#CONFIG_X86_X32)  | N/A | N/A | N/A | N/A | N/A | N/A | 
|  [`CONFIG_X86_X32_ABI`](#CONFIG_X86_X32_ABI)  | N/A |  n  | N/A |  n  | N/A |  n  | 

### x86-64 Support
<a name="CONFIG_X86_64"></a>

 Base x86-64 support includes the Physical Address Extension (PAE) and no-execute (NX) bit support. This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### AMD and Intel IOMMU support
<a name="kernel-x86-64-iommu"></a>

 The AL2023 kernel builds with support for the AMD and Intel IOMMUs. This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

 The `CONFIG_INTEL_IOMMU_DEFAULT_ON` option is not set, but can be enabled by passing `intel_iommu=on` to the kernel command line. Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. 

 The `CONFIG_INTEL_IOMMU_SVM` option is not currently enabled in AL2023. Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. 

### Support for 32bit userspace
<a name="kernel-hardening-32bit-support"></a>

**Important**  
 Support for 32bit x86 userspace is deprecated and support for running 32bit userspace binaries might be removed in a future major version of Amazon Linux. 

**Note**  
 While AL2023 no longer includes any 32bit packages, the kernel will still support running 32bit userspace. See [32bit x86 (i686) Packages](compare-with-al2.md#i686) for more information. 

 To support running 32bit userspace applications, AL2023 does not enable the `CONFIG_X86_VSYSCALL_EMULATION` option, and enables the `CONFIG_IA32_EMULATION`, `CONFIG_COMPAT`, and `CONFIG_X86_VSYSCALL_EMULATION` options. Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. 

 The x32 native 32-bit ABI for 64-bit processors is not enabled (`CONFIG_X86_X32` and `CONFIG_X86_X32_ABI`). This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### x86 Model Specific Register (MSR) support
<a name="CONFIG_X86_MSR"></a>

 The `CONFIG_X86_MSR` option is enabled in order to support `turbostat`. Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. 

### `modify_ldt` syscall
<a name="CONFIG_MODIFY_LDT_SYSCALL"></a>

 AL2023 does not allow user programs to modify the x86 Local Descriptor Table (LDT) with the `modify_ldt` syscall. This call is required to run 16-bit or segmented code, and its absence may break software such as `dosemu`, running some programs under WINE, and some very old threading libraries. This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### Remove kernel mapping in user mode
<a name="CONFIG_PAGE_TABLE_ISOLATION"></a>

 AL2023 configures the kernel so that the majority of kernel addresses are not mapped into userspace. This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### Randomize kernel memory sections
<a name="CONFIG_RANDOMIZE_MEMORY"></a>

 AL2023 configures the kernel to randomize the base virtual addresses of kernel memory sections. This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

## aarch64 specific Kernel Hardening options
<a name="kernel-hardening-aarch64"></a>


| `CONFIG` option | AL2023/6.1/aarch64 | AL2023/6.1/x86\$164 | AL2023/6.12/aarch64 | AL2023/6.12/x86\$164 | AL2023/6.18/aarch64 | AL2023/6.18/x86\$164 | 
| --- | --- | --- | --- | --- | --- | --- | 
|  [`CONFIG_ARM64_BTI`](#CONFIG_ARM64_BTI)  |  y  | N/A |  y  | N/A |  y  | N/A | 
|  [`CONFIG_ARM64_BTI_KERNEL`](#CONFIG_ARM64_BTI_KERNEL)  | N/A | N/A | N/A | N/A | N/A | N/A | 
|  [`CONFIG_ARM64_PTR_AUTH`](#CONFIG_ARM64_PTR_AUTH)  |  y  | N/A |  y  | N/A |  y  | N/A | 
|  [`CONFIG_ARM64_PTR_AUTH_KERNEL`](#CONFIG_ARM64_PTR_AUTH_KERNEL)  |  y  | N/A |  y  | N/A |  y  | N/A | 
|  [`CONFIG_ARM64_SW_TTBR0_PAN`](#CONFIG_ARM64_SW_TTBR0_PAN)  |  y  | N/A |  y  | N/A |  y  | N/A | 
|  [`CONFIG_UNMAP_KERNEL_AT_EL0`](#CONFIG_UNMAP_KERNEL_AT_EL0)  |  y  | N/A |  y  | N/A |  y  | N/A | 

### Branch Target Identification
<a name="CONFIG_ARM64_BTI"></a>

 The AL2023 kernel enables support for Branch Target Identification (`CONFIG_ARM64_BTI`). This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

 The `CONFIG_ARM64_BTI_KERNEL` option is not enabled in AL2023 as it is built with GCC, and support for building the kernel with this option is [currently disabled in the upstream kernel](https://github.com/torvalds/linux/commit/c0a454b9044fdc99486853aa424e5b3be2107078) due to a [gcc bug](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671). Although this option is one of the [Kernel Self Protection Project (KSPP) Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings), AL2023 does not set this configuration option to what KSPP recommends. 

### Pointer Authentication (`CONFIG_ARM64_PTR_AUTH`)
<a name="CONFIG_ARM64_PTR_AUTH"></a>

 The AL2023 kernel is built with support for the Pointer Authentication extension (part of the ARMv8.3 Extensions), which can be used to help mitigate Return Oriented Programming (ROP) techniques. The required hardware support for pointer authentication on [Graviton](https://aws.amazon.com/ec2/graviton) was introduced with Graviton 3. 

 The `CONFIG_ARM64_PTR_AUTH` option is enabled and provides support for pointer authentication for userspace. Because the `CONFIG_ARM64_PTR_AUTH_KERNEL` option is also enabled, the AL2023 kernel is able to use the return address protection for itself. 

 This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### Emulate Privileged Access Never using `TTBR0_EL1` switching
<a name="CONFIG_ARM64_SW_TTBR0_PAN"></a>

 This option prevents the kernel from accessing userspace memory directly, with `TTBR0_EL1` being only temporarily set to a valid value by the user access routines. 

 This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

### Unmap kernel when running in userspace
<a name="CONFIG_UNMAP_KERNEL_AT_EL0"></a>

 The AL2023 kernel is configured to unmap the kernel when running in userspace (`CONFIG_UNMAP_KERNEL_AT_EL0`). This option is one of the [Kernel Self Protection Project Recommended Settings](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings). 

# Repository metadata signing in AL2023
<a name="repo-metadata-signing"></a>

Starting with release `2023.11.20260406`, AL2023 repositories include cryptographic signatures for repository metadata. Each repository's `repomd.xml` file is accompanied by a detached GPG signature file (`repomd.xml.asc`) that you can use to verify the authenticity and integrity of the repository metadata before packages are downloaded.

This signing is in addition to the existing RPM package signing (`gpgcheck`), which verifies individual packages. Repository metadata signing verifies the metadata that describes the contents of the repository, such as the list of available packages and their checksums.

## How repository metadata signing works
<a name="repo-metadata-signing-overview"></a>

When AL2023 repositories are published, the repository metadata (`repomd.xml`) is signed using an AWS KMS key. The resulting detached signature (`repomd.xml.asc`) is placed alongside the metadata in the repository.

When you enable `repo_gpgcheck` in your repository configuration, DNF automatically downloads and verifies the `repomd.xml.asc` signature against the GPG public key before using the repository metadata. If the signature verification fails, DNF rejects the repository metadata and does not proceed with package operations from that repository. For more information about `repo_gpgcheck`, see the [DNF Configuration Reference](https://dnf.readthedocs.io/en/latest/conf_ref.html).

The following AL2023 repositories include signed metadata:
+ Core repository (`amazonlinux`)
+ Kernel Livepatch repository (`kernel-livepatch`)
+ NVIDIA repository (`amazonlinux-nvidia`)
+ Supplementary Packages for Amazon Linux repository (`amazonlinux-spal`)

## Difference between `gpgcheck` and `repo_gpgcheck`
<a name="repo-metadata-signing-gpgcheck-vs-repo-gpgcheck"></a>


| Setting | What it verifies | Default in AL2023 | 
| --- | --- | --- | 
| gpgcheck=1 | Verifies the GPG signature of individual RPM packages before installation. | Enabled | 
| repo\$1gpgcheck=1 | Verifies the GPG signature of the repository metadata (repomd.xml) before using the repository. | Disabled (enabled by default starting with the 2023.12 quarterly release) | 

We strongly recommend that you enable both `gpgcheck` and `repo_gpgcheck`. This ensures that both the repository metadata and the individual packages are verified before use.

## Enabling repository metadata verification
<a name="repo-metadata-signing-enable"></a>

You can enable repository metadata verification for individual repositories by updating their configuration files.

**Important**  
Starting with the `2023.12` quarterly release, `repo_gpgcheck=1` will be enabled by default in the AL2023 repository configuration files.

### Enable for a specific repository
<a name="repo-metadata-signing-enable-per-repo"></a>

The AL2023 repository configuration files in `/etc/yum.repos.d/` set `repo_gpgcheck=0` by default. To enable repository metadata verification, change this value to `1` in the repository configuration. For example, to enable it for the core repository:

```
[amazonlinux]
name=Amazon Linux 2023 repository
...
gpgcheck=1
repo_gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-linux-2023
```

## Verifying that repository metadata signing is working
<a name="repo-metadata-signing-verify"></a>

After enabling `repo_gpgcheck=1`, you can verify that metadata verification is working by clearing the DNF cache and refreshing the metadata:

```
[ec2-user ~]$ sudo dnf clean metadata
[ec2-user ~]$ sudo dnf makecache
```

If the metadata verification succeeds, DNF imports the GPG key (if not already imported) and creates the metadata cache without errors. You will see output similar to the following:

```
Amazon Linux 2023 repository                    1.7 MB/s | 1.8 kB     00:00
Importing GPG key 0xD832C631:
 Userid     : "Amazon Linux <amazon-linux@amazon.com>"
 Fingerprint: B21C 50FA 44A9 9720 EAA7 2F7F E951 904A D832 C631
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-linux-2023
Amazon Linux 2023 repository                      18 MB/s |  55 MB     00:03
Metadata cache created.
```

If the signature verification fails, DNF displays an error message indicating a GPG signature verification failure and metadata cache creation fails.

## GPG public keys for AL2023 repositories
<a name="repo-metadata-signing-gpg-keys"></a>

The GPG public keys used for repository metadata verification are installed by the corresponding repository configuration RPMs to `/etc/pki/rpm-gpg/`. The following table lists the public keys used by each repository.


| Repository | Package signing key | Repodata signing key | Distributed in | 
| --- | --- | --- | --- | 
| Core (amazonlinux) | RPM-GPG-KEY-amazon-linux-2023 | RPM-GPG-KEY-amazon-linux-2023 | system-release | 
| Kernel Livepatch (kernel-livepatch) | RPM-GPG-KEY-amazon-linux-2023 | RPM-GPG-KEY-amazon-linux-2023 | system-release | 
| NVIDIA (amazonlinux-nvidia) | RPM-GPG-KEY-NVIDIA-D42D0685 | RPM-GPG-KEY-amazon-linux-2023-nvidia | nvidia-release | 
| SPAL (amazonlinux-spal) | RPM-GPG-KEY-amazonlinux-spal | RPM-GPG-KEY-amazonlinux-spal | spal-release | 

These keys are automatically installed when you install the corresponding repository configuration RPM.

# UEFI Secure Boot on AL2023
<a name="uefi-secure-boot"></a>

AL2023 supports UEFI Secure Boot starting with release 2023.1. You must use AL2023 with Amazon EC2 instances that support both UEFI and UEFI Secure Boot. For more information, see [Requirements to launch an Amazon EC2 instance in UEFI boot mode](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/launch-instance-boot-mode.html) in the *Amazon EC2 User Guide*.

AL2023 instances with UEFI Secure Boot enabled accept only kernel level code, including the Linux kernel as well as modules, that are signed by Amazon so you can ensure that your instance only runs kernel level codes signed by AWS.

 For more information about Amazon EC2 instances and UEFI Secure Boot, see [UEFI Secure Boot for Amazon EC2 instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/uefi-secure-boot.html) in the *Amazon EC2 User Guide*.

**Prerequisites**
+ You must be using an AMI with AL2023 release 2023.1 or higher.
+ The instance type must support UEFI Secure Boot. For more information, see [Requirements to launch an Amazon EC2 instance in UEFI boot mode](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/launch-instance-boot-mode.html) in the *Amazon EC2 User Guide*.

## Enable UEFI Secure Boot on AL2023
<a name="enablement"></a>

Standard AL2023 AMIs incorporate a bootloader and a kernel signed by our keys. You can enable UEFI Secure Boot either by enrolling existing instances or creating AMIs with UEFI Secure Boot pre-enabled by registering an image from a snapshot. UEFI Secure Boot isn't enabled by default on the standard AL2023 AMIs.

The boot mode of AL2023 AMIs is set to `uefi-preferred` which ensures that instances launched with these AMIs will use the UEFI firmware, if the instance type supports UEFI. If the instance type doesn't support UEFI, the instance is launched with Legacy BIOS firmware. When an instance launches in Legacy BIOS mode, UEFI Secure Boot isn't enforced.

For more information about AMI boot modes on Amazon EC2 instances, see [Instance launch behavior with Amazon EC2 boot modes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot.html) in the *Amazon EC2 User Guide*.

**Topics**
+ [Enable UEFI Secure Boot on AL2023](#enablement)
+ [Enrollment of an existing instance](#enrollment-existing-instance)
+ [Register image from snapshot](#secure-boot-amis)
+ [Revocation updates](#revocation-updates)
+ [How UEFI Secure Boot works on AL2023](#shim-use)
+ [Enrolling your own keys](#enrolling-own-keys)

## Enrollment of an existing instance
<a name="enrollment-existing-instance"></a>

To enroll an existing instance, populate the specific UEFI firmware variables with a set of keys that enable the firmware to verify the bootloader and the bootloader to verify the kernel on the next boot.

1. Amazon Linux provides a tool to simplify the enrollment process. Run the following command to provision the instance with the necessary set of keys and certificates. 

   ```
   sudo amazon-linux-sb enroll
   ```

1. Run the following command to reboot the instance. After the instance is rebooted, UEFI Secure Boot will be enabled. 

   ```
   sudo reboot
   ```

**Note**  
Amazon Linux AMIs currently don't support Nitro Trusted Platform Module (NitroTPM). If you need NitroTPM in addition to UEFI Secure Boot, use the information in the following section.

## Register image from snapshot
<a name="secure-boot-amis"></a>

When registering an AMI from a snapshot of an Amazon EBS root volume using the Amazon EC2 `register-image` API, you can provision the AMI with a binary blob that contains the state of the UEFI variable store. By providing the AL2023 `UefiData`, you enable UEFI Secure Boot and don't need to follow the steps in the previous section.

For more information about creating and using a binary blob, see [Create a binary blob containing a pre-filled variable store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-ami-with-uefi-secure-boot.html#uefi-secure-boot-optionB) in the *Amazon EC2 User Guide*.

AL2023 provides a pre-built binary blob that can be used directly on Amazon EC2 instances. The binary blob is located in `/usr/share/amazon-linux-sb-keys/uefi.vars` on an running instance. This blob is provided by the `amazon-linux-sb-keys` RPM package which is installed by default on AL2023 AMIs starting with release 2023.1.

**Note**  
To ensure that you are using the latest version of keys and revocations, use the blob from the same release of AL2023 that you use to create the AMI.

When registering an image, we recommend using the `BootMode` parameter of the [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RegisterImage.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RegisterImage.html) API set to `uefi`. This allows you to enable NitroTPM by setting the `TpmSupport` parameter to `v2.0`. Also, setting `BootMode` to `uefi` ensures that UEFI Secure Boot is enabled and can't be disabled by accident when switching to an instance type that doesn't support UEFI.

For more information about NitroTPM, see [NitroTPM for Amazon EC2 instances ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/nitrotpm.html) in the *Amazon EC2 User Guide*.

## Revocation updates
<a name="revocation-updates"></a>

It may be necessary for Amazon Linux to distribute a new version of the bootloader `grub2` or the Linux kernel signed with updated keys. In that case, the old key may need to be revoked to prevent the chance of allowing exploitable bugs from previous versions of the bootloader to bypass the UEFI Secure Boot verification process.

Package updates to the `grub2`or `kernel` packages always automatically update the list of revocations into the UEFI variable store of the running instance. This means that with UEFI Secure Boot enabled, you can no longer run the old version of a package after installing a security update for the package.

## How UEFI Secure Boot works on AL2023
<a name="shim-use"></a>

Unlike other Linux distributions, Amazon Linux doesn’t provide an additional component, called a shim, to act as the first stage bootloader. The shim is generally signed with Microsoft keys. For example, on Linux distributions with the shim, the shim loads the `grub2` bootloader which uses the shim’s own code to verify the Linux kernel. Additionally, the shim maintains its own set of keys and revocations in the Machine Owner Key (MOK) database located in the UEFI variable store and controlled with the `mokutil` tool.

Amazon Linux doesn’t provide a shim. Because the AMI owner controls the UEFI variables, this intermediary step isn't needed and would adversely affect launch and boot times. Also, we chose not to include trust to any vendor keys by default, to reduce the chance that undesired binaries could get executed. As always, customers can include binaries if they chose to do so. 

With Amazon Linux, UEFI directly loads and verifies our `grub2` bootloader. The `grub2` bootloader was modified to use UEFI to verify the Linux kernel after loading it. Thus, the Linux Kernel is verified using the same certificates stored in the normal UEFI `db` variable (authorized key database) and tested against the same `dbx` variable (revocations database) as the bootloader and other UEFI binaries. Because we provide our own PK and KEK keys, which control access to the db database and the dbx database, we can distribute signed updates and revocations as needed without an intermediary such as the shim.

For more information about UEFI Secure Boot, see [How UEFI Secure Boot works with Amazon EC2 instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/how-uefi-secure-boot-works.html) in the *Amazon EC2 User Guide*.

## Enrolling your own keys
<a name="enrolling-own-keys"></a>

As documented in the previous section, Amazon Linux does not require a `shim` for UEFI Secure Boot on Amazon EC2. When you're reading documentation for other Linux distributions, you may find documentation for managing the Machine Owner Key (MOK) database using `mokutil`, which is not present on AL2023. The `shim` and MOK environments work around some limitations of key enrollment in UEFI Firmware that aren't applicable to how Amazon EC2 implements UEFI Secure Boot. With Amazon EC2 there are mechanisms to easily directly manipulate the keys in the UEFI variable store.

If you want to enroll your own keys, you can do so either by manipulating the variable store within an existing instance (see [ Add keys to the variable store from within the instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-ami-with-uefi-secure-boot.html#uefi-secure-boot-optionA)) or by constructing a binary blob that's prefilled (see [ Create a binary blob containing a pre-filled variable store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-ami-with-uefi-secure-boot.html#uefi-secure-boot-optionB)).