SELinux is short for Security-Enhanced Linux, and is a security module built into the Linux kernel which provides Mandatory Access Control (MAC). It was originally developed by the National Security Agency to harden Linux for use in secure environments, and acts as a highly granular, "default deny" security shield. Even if a process or root-level is compromised, it strictly limits what resources such as files/directories, network ports and such can be accessed, and what actions may be taken, down to even individual syscalls (the functions programs use to enter the kernel) into the kernel on individual files. It goes well beyond the old-style read/write/execute by owner/group/world permissions to pinpoint accuracy in protecting your system. I like to think of it as something similar to a firewall, but between processes (and resources) instead of networks.
Good resources include:
- What is SELinux? (by Red Hat)
- What is SELinux? (by GeeksForGeeks)
- What Is SELinux And Why It Matters For Linux Security (by SUSE)
- What is the relation/difference between SELinux and Firewalld? (from Fedora Project)
- Using SELinux (from the Red Hat Enterprise Linux 9 documentation)
- Troubleshooting problems related to SELinux (a specific chapter from the above)
- How to Troubleshoot SELinux Permission Denials (a blog post on OneUptime)
- SELinux Cheat Sheet (from Andreas Karis's Blog)
Regarding SELinux, I feel that any system engineer/developer/administrator should become familiar with it (or its alternatives, if using a different distro or OS) and use it. Indeed, I would go so far as to say that where possible, it is negligent to run a system without having SELinux or its equivalent running in what SELinux calls "enforcing" mode. And I say this of home development machines as well, since without having it enabled during development, how is the developer to test and develop the modules necessary to control the access of any software. And for any machine even indirectly exposed to the Internet, either on an incoming or outgoing traffic basis, this necessity goes up by several orders of magnitude.
This may seem a bit arrogant of me, but I come from a background where I was held directly responsible for doing my part to insure the security of systems for which I was responsible for the OS at both CompuServe and Bell Labs Messaging, among other places, where it could show up in my annual performance reviews. Just ask Google or your favorite search engine "what is the term for when you do not use all the tools to protect against a security failure and you suffer a breach" to see why I don't agree with it being arrogant, but instead feel it is so important.