This past week, I saw an article about CERN moving more than 2200 specialized computers from RHEL based distros to Debian. And my years of experience with both UN*X and network security tell me that this is a really big deal, and potentially a big mistake on both Red Hat's (IBM's) part as well as on the part of CERN.
A bit of background. I have a Red Hat Developer subscription, and some time ago, I tried to install RHEL 10 on my main hypervisor machine, a "massive" Dell R720. And when did, I got an error telling me that the CPU did not have the proper "microarchitecture ", which is a fancy way of saying that while a Xeon(R) processor, it was lacking some newer instructions which have been added to the newer versions of the processor. Presently, there are four levels. The first was the baseline x86-64-v1 which all 64-bit processors, going clear back to the first processors like the AMD K8 and Intel Prescott processors have. Then there is the x86-64-v2, which added new instructions/features around 2008/2009 for the Intel Nehalem and 2011 for the AMD Bulldozer (gotta love the names). A few years later, they did it again, creating the x86-64-v3 microarchitecture, which came out in 2013 with the Intel Haswell and 2015 with the AMD Excavator. And then, most recently, there is the x86-64-v4 microarchitecture, which as introduced in 2017 with the Intel Skylake-X, and followed on with the AMD Zen 4 processors. And unlike the transition from the x86-32 to x86-64, the difference is often just a small number of instructions or manipulate some of the specialty registers... yet...
First, the mistake on the part of Red Hat is that governments and federally funded labs, like CERN, or NRAO where I work, which according to Red Hat's 10-K filing, represents about 10% of their sales in 2019 before being swallowed by IBM. Often times, these places have older servers, switches and other computing gear. Meanwhile, Red Hat unilaterally changed RHEL 10 to require the x86_64_v3 microarchitecture level and dropped support for the 32-bit processors entirely, while other distros as well as other OSes like the BSD variants still often support those older processors even today. This means that they risk having a large number of their customers unable to upgrade to RHEL 10, when RHEL 9 enters the stage in its lifecycle where it will just be receiving critical and security related fixes. And this does not even begin to look at things like corporations or universities, some of which can be just as behind the curve, due to things like tax depreciation laws, reluctance to spend, etc.
The potential big mistake on the part of CERN is that unless they take the extra steps necessary to switch their machines from using AppArmor to using SELinux, they will in effect be doing the computing equivalent walking down the street with the waist of their pants around their knees. AppArmor, while easy to administer, because of its design, is not as secure as SELinux, making it potentially more vulnerable to attacks by bad actors, where because of their visibility, CERN could be considered a high-value target. And, to implement SELinux, they will have to install additional packages, change boot parameters, and take other steps to get the same security which RHEL provides from the very first boot of the system. For example, to look at two common processes, sshd and apache2/httpd, on a RHEL based machine, these two come with a set of very restrictive policies "out of the box". This means that if someone does manage to say gain access through the web server, they cannot read the files for SSH. Indeed, almost all processes on a RHEL system including the kernel "processes", other than those directly dealing with a user's session, have policies in place which protects the system. But for even the latest Debian system, most of the processes are running "unconfined", including sshd and apache2. This means that either one of them becomes an attack surface through which a bad actor could compromise the system. The only plus for AppArmor is its ease to administer, where SELinux, for some reason, is perceived as being difficult to manage, and people just want to switch it from its "enforcing" mode to "inform" mode, where it allows but logs accesses to parts of the system.
So yea, a far from perfect world.