Amazon Linux 2022 introduces many exciting new security features and best practices. In this post, we will:

• Explore the significant changes in Amazon Linux 2022
• See precisely how the new features will help you maintain a secure architecture
• Learn how Mondoo can help you ensure that you’re following the best security practices when managing your AWS infrastructure

What’s new in Amazon Linux 2022

Amazon Linux 2022 is, in some ways, a complete re-imagining of what Amazon Linux should be. In addition to the new security and performance features that come with any major upgrade to the Linux kernel, Amazon Linux also includes changes that will be important to people looking for stability and predictability from Amazon. Major changes include new upstream definitions, newly default-enabled security features, a new predictable release cadence, and a change to the way package repositories are handled that Amazon is calling “version locking.”

New upstream definitions

The first big change to note about Amazon Linux 2022 is that it’s moved to a new upstream. While Amazon Linux 2 is based on the Red Hat Enterprise Linux (RHEL) distribution, each major release of Amazon Linux 2022 will instead be based on a major upstream release of Fedora.

From there, Amazon will replace specific packages from other upstreams as they see fit. The Amazon Linux 2022 preview available now is based on Fedora 34. The full release will be based on Fedora 35.

One big divergence from Fedora linux is that Amazon sources kernels directly from kernel.org’s LTS choices, independently of the Fedora release they’re based on.

SELinux enforcing by default

Long-term Linux systems administrators may have read “SELinux enforcing by default” and winced a little bit. For many years, a key first troubleshooting step when dealing with Linux issues was, “Did somebody accidentally enable SELinux?”

But for Amazon Linux 2022, Amazon has made a key selling point out of the fact that “Amazon Linux 2022 has SELinux enabled and enforced by default.” They go on to say, “SELinux is a security module providing access control policies. It is widely used in the industry to lock down Linux servers and to protect against malicious activity.”

All of this is true, but without further context it’s hard to know what it means for day-to-day use. SELinux has many modes of operation and many types of policies it can enforce. What we all really need to know is which parts of SELinux, exactly, are being enforced by default?

So we did some digging. By default, two packages of SELinux policy are installed in Amazon Linux 2022:

• selinux-policy
• selinux-policy-targeted

Both are built from the repository shared here: https://github.com/fedora-selinux/selinux-policy/tree/rawhide/policy

What exactly is the targeted policy bundle?

First, we’re going to need to define an SELinux domain. Put simply, a domain is an object representing a set of permissions. Every process is assigned a domain.

It’s easiest here to quote the documentation: “When using targeted policy, processes that are targeted run in a confined domain, and processes that are not targeted run in an unconfined domain. For example, by default, logged-in users run in the unconfined_t domain, and system processes started by init run in the initrc_t domain; both of these domains are unconfined.”

Processes running in an unconfined domain can allocate writable memory and execute it.

However, almost every process that listens on the network runs in a confined domain, as do processes that execute as root on behalf of the user, such as passwd. The sshd process runs in the sshd_t domain, the httpd process runs in the httpd_t domain, and so on.

In this way, if a process confined by a domain is breached by an attacker, then an attacker’s access to the system should still be limited. For instance, even if httpd is loosely configured, attackers will still be blocked by SELinux from accessing files that belong to Samba.

When Amazon says that Amazon Linux runs with “SELinux enforcing by default,” this is what they mean: Targeted policy is enabled and enforcing by default.

‍

Release cadence

Historically, Amazon Linux has not had a regular release cadence. The original Amazon Linux shipped in September 2010 and had a ten-year support cycle that ended in December 2020. The follow-up, Amazon Linux 2, was released in December 2017 and is supported until June 2023. The lack of predictability in this cycle has made it difficult for administrators to plan upgrades to EC2 infrastructure.

That all changes for Amazon Linux 2022. Following Ubuntu’s lead, Amazon has adopted an every-two-year release cycle for LTS distributions. Every LTS release will receive two years of standard support and a three-year maintenance phase.

Amazon plans to release quarterly updates with security updates, bug fixes, new features, and packages throughout the standard support window. In addition, Amazon pledges to release security patches and critical bug fixes during the maintenance phase.

What will that look like in practice? Amazon provides this graph:

By adopting a more predictable lifecycle for Amazon Linux, Amazon has made it easier for cloud administrators to plan their upgrade and maintenance cycles over the long term.

Version locking

Version locking is a feature that requires some background to explain.

Modern Linux distributions support a vast variety of software and use cases. They support dozens, if not hundreds, of different programming languages. Using the same version of Linux, you can run machine learning tools, graphical render farms, and bitcoin miners; host online video game matches; or just automate the lights in your house.

And it’s not just the workloads that are different but the environments, too: You can run the same Linux distribution on tiny embedded systems, in cloud environments, on laptops, or on giant servers that stand 6’2” tall.

But it doesn’t make sense to install machine learning tools on a tiny embedded system that will control your garage door opener. So how do we make sure that our systems only contain the features we need, without a lot of extraneous cruft that just takes up space on a disk?

Modern Linux distributions solve this problem with package repositories. A package repository is a set of software installers on the internet intended for use with a particular Linux distribution. Most modern Linux installations come with a minimal set of software.

Administrators use automation tools to search for and install new software on their systems from the repository. The packages in vendor-provided repositories are considered “blessed” by the vendor, and support for the packages is included in the LTS support agreement.

In Amazon Linux 2, Amazon used a rolling-update model to handle feature and security upgrades to the packages in their repository. Put another way, Amazon maintained one canonical repository of blessed packages for Amazon Linux 2 and updated the packages stored there as needed.

For example, if you launch an older version of the Amazon Linux AMI, such as 2017.09 or earlier, and run yum update -y to upgrade packages, you will have the latest packages available today. In practice, this means that EC2 instances created from the same base image at different points in time may have different package sets, depending on when they were last updated.

Multiply this by dozens, hundreds, or thousands of instances, and management becomes a huge problem. With rolling package updates, how do I know which version of OpenSSL is installed on all of my different EC2 instances?

Enter version locking! Beginning with Amazon Linux 2022, each release of Amazon Linux will be locked to a corresponding package repository. Because of this, system administrators can be confident that running dnf upgrade on instances instantiated from the same Amazon Linux AMI will have the same package set, even if the upgrades happen months or even years apart.

Amazon will release security updates to every supported version of Amazon Linux 2022, but will hold feature upgrades for the next quarterly release. With these assurances, you can be confident that running dnf upgrade on any Amazon Linux 2022.0 system will have a predictable result, regardless of when you run the command.

Even better, if you want to upgrade a long-lived instance from Amazon Linux 2022.0 to Amazon Linux 2022.1, it’s as simple as pointing it at the Amazon Linux 2022.1 package repository with the dnf package manager and running a few commands.

Administrators who prefer the older, rolling model of system updates can select the “latest” version, which will always point to the most recent version of the Amazon Linux 2022 repositories.

Mondoo and Amazon Linux 2022

Mondoo can already scan Amazon Linux 2022 instances, whether they’re running on traditional x86 architecture, on ARM-based graviton architecture, or even in a local development environment or container on your laptop. Because Mondoo already imports the advisory & vulnerability feeds for Amazon Linux 2022, you can use Mondoo to check your systems for vulnerabilities today.

And when the Center for Internet Security publishes their Amazon Linux 2022 benchmark, Mondoo will have built-in policies ready to go; you’ll be able to check your systems for known vulnerabilities and common misconfigurations. Mondoo will be a key tool for many of our customers looking to upgrade to the latest Amazon Linux release.

Conclusion

Amazon Linux 2022 represents a major shift in how Amazon delivers their Linux platform, and charts a strong forward roadmap into the future. With the new upstream definitions, SELinux targeting enabled by default, version locking, and a predictable release cadence, people who rely on Amazon Linux to run their infrastructure have a lot to look forward to. Mondoo is excited to help people take the step into a more secure, more performant future.

‍