SELinux is not the only MAC/RBAC out there. On Arch, there most certainly are MAC/RBAC systens that perform very well, and there are other Linux security systems and methods of hardening.
Arch users usually have built their own system entirely themselves. That means that they are supposed to not just follow the manual, but actually understand every step of the way. By understanding everything on their system, what it does and what it's role is, arch users can of course configure their system very tightly, with not much exposure surface. However, it's also clear that Arch is not the world's preferred enterprise distro.
A MAC/RBAC, whether it is SELinux like Fedora uses and like Android uses for instance, or AppArmor like OpenSuSE uses but also like Ubuntu uses for instance, or Tomoyo like many Arch users use, or GR.SEC like many Debian installs use, etc... is a safety net. It is an access control system that uses logical rules about what would be normal for different apps and processes to do on a system or not. Most prejudicial attacks are based on CVE's, which are bugs basically. In Linux, most processes stay in userland, and in most distros, that would be very limiting for an attacker able to exploit a bug in such a process, because he could only get to user session data basically, which might be bad enough for that user, but the system wouldn't be endangered. The problem is when an exploit allows that hacker to escalate his privileges to root level, because at that point, he would get access to the system. A MAC filters the access to the system by applying rules about what should and should not have access to the system. An RBAC goes further and looks at what would be "normal" to even ask access to a certain part of the system. So even if a hacker would be able to use an exploit in a userspace process, he would not get past the MAC/RBAC in most cases. This actually works remarkably well. It's the reason Android is still a thing and didn't completely crash and burn basically.
SELinux is open source, but it's actually serious shit, it's military grade protection, it was actually originally made by the NSA, and is still being supported by the NSA. Tomoyo was originally developed by the Japanese Secret Service, but then given to the open source community as the Japanese Secret Service also migrated to SELinux. In the modern day crazy world full of corporate data leaching and all kinds of hacks and exploits everywhere, a MAC/RBAC is basically a necessity. SELinux is the best performing one, also because it has really benefitted from the fact that it has become the standard on Android, which has boosted development.
If you install nVidia proprietary drivers, you but yourself in harms way in two very important ways:
1. You are allowing a commercial company to write a binary blob, a big chunk of code that is not open source and can't be inspected, right into your kernel, right into the heart of your system, where no security mechanism can have any effect on it, and it has all the privileges it wants. nVidia is known for the pay-as-you-go driver updates and spyware in Windows, are you letting a notoriously nefarious company like that infect the heart of your system with a big chunk of unknown software?
2. You are disabling any MAC/RBAC for the entire nVidia driver, which means that any exploit of that driver will find it's way right into the kernel of your machine, without any filter or safety net, so basically you're killing any and all security on your system. That means that the tinyest exploit in any part of the nVidia software (which is not open source so nobody would be able to see whether or not there even was such an exploit, or the exploit might even be planted by nVidia and nobody would know), immediately leads to a possible complete system takeover and access to all data, even encrypted data.
And for what? For a port of a Windows driver... it's not even a driver made for linux.
There is an open source driver for linux. It is actually not provided by nVidia. It was a kickstarter project a couple of years ago. This problem of not having safe nVidia drivers is so huge, that people actually donated a lot of money to a small group of people in order to:
- go out and buy nVidia GPU cards;
- rent a laser and an electron microscope;
- disect the nVidia GPU layer by layer with the laser and examine it with the electron microscope;
- reverse engineer the GPU architecture by analysing those slices;
- make an open source driver from scratch based on that reverse engineering data;
That has actually worked out to be pretty good, it's the open source nvidia driver for linux. The only thing that could not be reverse engineered, is the instruction set of the GPU, meaning that some functionality is not on the open source driver, but most importantly, the instructions to make the GPU clock up are unknown. nVidia refuses to give those instructions, so that the open source drivers would remain limited to the lowest power state at all time. Reverse engineering and experimenting continues though, and some power states have already been unlocked. There will come a time where the entire nVidia architecture will be open sourced just because nVidia refuses to document its hardware.
There is also another serious pitfall of proprietary drivers, and that is that they - not being open source and being ports from Windows drivers - can only do their own thing, they can't really work together with the rest of the system, they can't use the huge amount of deep integration and optimalisation possibilities of the linux platform and of the linux kernel. One of these functions of linux is that the linux kernel can always detect the mode of any display attached at any point in time, and can immediately set the appropriate mode if that display is class compliant, which is the case for 99% of all displays basically, from vidwalls to special displays for viewing X-rays in hospitals, the linux kernel knows them all and can immediately set the graphical mode correctly, even with hot plugging. This is only possible with KMS drivers, open source drivers. The nVidia proprietary driver is the only current driver on linux that can't do that. On top of that, since about the end of 2012, nVidia has invested much less in maintenance of their Windows driver port for Linux, because Linux has ramped up development because of mobile development, Samsung, Qualcomm, etc have really boosted Linux kernel development enormously, and nVidia just couldn't keep up without stepping up their effort, so they basically gave up. That means that there are often display mismatches, unrecognized displays, general problems with resolutions and refresh rates.
These problems are specific to nVidia only, so they make it a niche problem. Intel is the world's market leader in GPU's by far, and has ever only had open source drivers. AMD has been developing mainly for open source for years, since they launched their hybrid computing API's in 2012 or so. The current AMD driver is an open source driver like Intel's, however, there are some optional proprietary extensions that some people might want to use (so-called amdgpu-pro), but those do not require binary blobs nor disabling the security systems, they are designed to run unprivileged in userspace, the are designed to not have access to the system, but to work with the verifiable open source code on the system.
So this huge security problem is typical for nVidia and only affects nVidia.