I can't say I've seen the same, so I dug into it. There's a good list from RedHat[1] on CVEs SELinux mitigated. I went through them:
- CVE-2016-9962 - Bypasses Apparmor [2], mitigated by SELinux
- CVE-2022-0492 - Apparmor and Seccomp also protect against
- CVE-2019-5736 - Mixed, blocked by the default SELinux policy in RHEL (not Fedora), not blocked by the default AppArmor policy[3]
- CVE-2021-3156 - This one is not a good one for RedHat to put on the list. SELinux by default doesn't protect against it, Debian 10 at the time had a Linux security feature enabled (fs.protected_symlinks) that helped mitigate it, and additionally CVE-2021-23240 came out which had similar effects but only occurred on SELinux systems.
- CVE-2019-9213 - Not mitigated by AppArmor, mitigated by SELinux
- CVE-2019-13272 - Not mitigated by AppArmor, not mitigated by default SELinux policy, but easy to mitigate by enabling boolean. I'd consider this a win for SELinux, but only just.
While digging into this more, I came across this BlackHat talk[4] which really quantifies how SELinux improves security (though doesn't contrast it with AppArmor). I also came across a paper on usability of SELinux and AppArmor[5] which brings up an interesting point: If the tool is too complex, even if it's more powerful, more often than not it won't end up having better results.
That's all to say, I think if you're willing to invest a lot of time into it (say you want to make security your niche in your development career), SELinux is still the best. But I can see why many may gravitate towards AppArmor so as to not make perfect the enemy of good. That said, I still wish Debian had a choice between the two, right now SELinux isn't really doable without a lot of work.
- CVE-2016-9962 - Bypasses Apparmor [2], mitigated by SELinux
- CVE-2022-0492 - Apparmor and Seccomp also protect against
- CVE-2019-5736 - Mixed, blocked by the default SELinux policy in RHEL (not Fedora), not blocked by the default AppArmor policy[3]
- CVE-2021-3156 - This one is not a good one for RedHat to put on the list. SELinux by default doesn't protect against it, Debian 10 at the time had a Linux security feature enabled (fs.protected_symlinks) that helped mitigate it, and additionally CVE-2021-23240 came out which had similar effects but only occurred on SELinux systems.
- CVE-2019-9213 - Not mitigated by AppArmor, mitigated by SELinux
- CVE-2019-13272 - Not mitigated by AppArmor, not mitigated by default SELinux policy, but easy to mitigate by enabling boolean. I'd consider this a win for SELinux, but only just.
While digging into this more, I came across this BlackHat talk[4] which really quantifies how SELinux improves security (though doesn't contrast it with AppArmor). I also came across a paper on usability of SELinux and AppArmor[5] which brings up an interesting point: If the tool is too complex, even if it's more powerful, more often than not it won't end up having better results.
That's all to say, I think if you're willing to invest a lot of time into it (say you want to make security your niche in your development career), SELinux is still the best. But I can see why many may gravitate towards AppArmor so as to not make perfect the enemy of good. That said, I still wish Debian had a choice between the two, right now SELinux isn't really doable without a lot of work.
[1]: https://access.redhat.com/solutions/7032454
[2]: https://github.com/opencontainers/runc/issues/2128
[3]: https://www.cloudfoundry.org/blog/cve-2019-5736/
[4]: https://www.youtube.com/watch?v=EkL1sDMXRVk
[5]: https://researchportal.murdoch.edu.au/esploro/outputs/journa...