Last month, the preview of the next version of Amazon Linux was announced, and I (perhaps unsurprisingly?) have issues with it beyond its uninspired name of “Amazon Linux 2022.” Before I begin, I just want to make a plea that will almost certainly fall upon deaf ears: Please, please, please don’t email me about this. Yes, I know that your favorite distribution/OS is better than AL2022, I’m aware that my opinions are bad and I shouldn’t be allowed to touch a computer ever again, and your opinions on this are gospel. Just … don’t email me about it. Please. As a favor.
Fedora is the new fashion
Once upon a time, Amazon Linux and Amazon Linux 2 were based upon Red Hat Enterprise Linux, or RHEL, as their upstream Linux distribution. “Based upon” is doing a lot of heavy lifting here; Amazon Linux follows its upstream in the same way that ducks follow migrating caribou.
Now it tracks Fedora as its upstream provider. For those who aren’t familiar with Fedora, it can be considered to be Red Hat’s development version of the next RHEL. (Again: Please do not email me.) The Fedora community releases new versions every six months and they’re supported for 13 months (or roughly half the lifespan of a Google consumer product). Fedora is woefully unsuited for the old way of running servers: that is to say, in a stable and supported manner that doesn’t require reimaging the machines every six months.
Some of the features found in Fedora are improvements, some are drawbacks, and most are just different in various ways. Remember back when everything you knew about init systems was tossed on its head because of systemd? If you don’t know what I’m talking about, oh!, how I envy you.
Most notably in AL2022: yum (for Yellowdog Updater, Modified) is no longer the package manager of choice, having been replaced by dnf. It works basically like yum did except it’s a whole new syntax because the authors clearly “dgaf.” That’s… okay, fine, whatever.
No, the big change that’s going to break the internet is the choice to enable SELinux by default.
SELinux what now?
SELinux is a 20-year-old system jointly developed by Red Hat and the U.S. National Security Agency whose intended purpose is to enhance the state of Linux security but in practice throws inscrutable errors that vex people until they snap and turn it off entirely.
Note, because you will need this later: The way to disable it is to run the command “setenforce 0” as root. To make it persist through reboots, set “SELINUX” to “disabled” in /etc/selinux/config.
See, Linux generally views security controls in terms of Access Control Lists, ownership, and permissions. SELinux goes a step beyond that and enforces a series of mandatory access controls, intent-based contextual permissions, and what presents entirely as sheer spite. It requires not only that you as the customer configure SELinux controls properly but that so do all of the packages that you install on the system, or it fails with mysterious reasons.
The audit2allow command helps you craft custom policies for SELinux, but you’ve gotta realize that SELinux is why it’s breaking in the first place, and it’ll get remarkably tiresome for customers to configure this across their fleets. I’m betting they won’t do it in most companies, and this translates into AL2022 ceding the AWS customer OS space almost entirely to Ubuntu in the coming years just because “the Amazon one is just kinda broken and we don’t know why.” I assure you, I’d love to be wrong almost as much as the Stop Disabling selinux web page that Red Hat’s Major Hayden so lovingly curates wants me to be wrong — but I just don’t see it happening.
The issue is one of human nature. “Doing things properly” gives way to “will you freaking ship already” and people take shortcuts. Once you’ve disabled SELinux across everything, it’s a colossal pain to reenable it and get everything set up properly. I’m not betting on people taking the time to get security right; I’m betting on their requirement for expediency and need to solve for business outcomes to mean that every shop that doesn’t employ someone well versed in the magic of SELinux to either disable it immediately or determine that AL2022 is somehow weirdly broken and avoid it. Either everyone needs to fix things and be a lot more diligent or people have to run setenforce 0. I know which one I’m banking on.
Other than that, though, no big problems
As for the rest of AL2022, it’s mostly fine. The two-year major release cycle (with quarterly minor releases) combined with a five-year support lifecycle for each release is sensible; you probably don’t want things older than that running in your cloud environment, though of course they are and will be. At general availability it will support kernel live patching so you won’t need to reboot to get security updates. As a counterpoint, by default, the plugin for managing repository versions will lock to the same version that was used to build the AMI (two syllables wrong, three syllables good!) you’re using, thus no security updates will be applied. This is a crappy plan versus RHEL and CentOS’s historical pattern of backporting security fixes, and I suspect we’ll rue the day when this was decided before too much longer.
And of course this is another attempt by AWS to say that they’re serious about contributing to open source, even though the primary benefits of this Linux distribution are only going to be felt when you’re paying by the hour to run them in your AWS environment (yes, you can theoretically run it on your own systems; I just don’t know why you’d choose to do that in isolation). Honestly, I suspect the longest holdup in releasing this new version of Amazon Linux came simply from their attempting to figure out what to call it.
