Don’t Disable SELinux | Into the Terminal 102

[@scottmcbrien6535]

So turns out finding SELinux content was much more difficult than I thought! However, This guide from Red Hat, Using SELinux: access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/using_selinux/index Seems much more use driven than the older Administering SELinux guide that was published with RHEL7. Additionally, there's this great analysis of how SELinux works to mitigate a CVE by Joe Brockmeier: www.redhat.com/en/blog/selinux-mitigates-container-vulnerability It walks through how SELinux functions with the lens of why the CVE is mitigated by SELinux, which exactly why we want to use it.

[@RedHatEnterpriseLinux]

Thanks for sharing, Scott!

[@queenannsrevenge100]

I am glad Red Hat finally moved to making SELinux harder to outright disable; I’ve told people for years that permissive is twice as good as disabling it, because they still get the logging that tells them when something suspicious is happening. Much like Shantanu said, my first two “why is something not working as it should” steps are temporarily setting SEL to passive and temp stopping fapolicy 😄

[@TheVoltDolt]

great video!

[@ReptilianXHologram]

I wish ya'll or even the people that maintain SElinux would have better documentation on how to write policies. Whether that be using .cil or the Refpolicy I just feel like the documentation that is out there sucks.

[@RedHatEnterpriseLinux]

SELinux is open source. If there are pieces you think are missing, feel free to dive in! Contribute! Share your knowledge!

[@scottmcbrien6535]

The more practical reason is that most people don't need the ability to do these things. As a result, there's not much info about it. Even if someone spent hours and hours and hours writing it, they wouldn't get a lot of views or use. Those that do need it typically are large enough that Red Hat can likely point them in the right direction to do the thing they want to do... Like seriously, I'm still trying to get people to NOT disable it 🙂

[@ReptilianXHologram]

@@scottmcbrien6535 I mean I agree on the views thing, but I still feel like it would get a decent amount of views if someone were to create a tutorial on how to write a simple policy for a simple application or even a simple shell script. I used to dabble in creating policies like almost 10 years ago now so I'm kind of rusty now, and there isn't really that much info on it.

[@SlinkyD]

I always turned it off since SE was introduced. All these years later and its still a cryptic pain. Even fresh installs.habe SEL notifications going off everywhere. And anything I needed to work, SEL was in the way, making things 100x difficult. So its always an instant disabling.

[@scottmcbrien6535]

Thanks for watching! As mentioned on the show, in RHEL3 when it was first introduced and RHEL4, when it was first significantly documented, I get it. I didn't start using it until a couple of minor update releases into RHEL4. RHEL 5, it was generally usable. RHEL6+ I think it's generally invisible (largely thanks to the continued improvement to the ruleset in the targeted policy). Also as mentioned late in the show, RHEL9+, you don't want to 'disable' it. You could set the default config to permissive mode, but you'll still get all the alerts about violations in that mode. It just doesn't stop things from occurring that are outside the configured policy. Keep in mind though that folks like the Red Hat Product Security team, when rating CVEs using the modified vendor CVSS score will assume that SELinux is enabled when determining their score for a vulnerability. I think this is the vulnerability Nate and I mentioned re: runc on the show: access.redhat.com/security/vulnerabilities/RHSB-2021-004 With SELinux in enforcing mode, using the targeted policy, the attack vector was blocked for anything other than container_t type files that would be in-scope for a container running, but maybe would not be natively accessible inside of their containerized runtime without a symlink outside. (which is pretty edge-case). But, IMO, saying 'its too hard' could apply to so.many.things. Why not ever use host-base firewalls? Or file permissions? or networks with non-octet bounded network mask descriptions? or systemd configurations? We learn new, and sometimes challenging things because it's a better way to operate our systems, I think SELinux is one of those worth learning.

[@RedHatEnterpriseLinux]

What types of applications are you running that would compete with the system defaults? - Eric