FWIW, I’ve worked at many RedHat shops over the years and I’ve never seen one where disabling SELinux wasn’t a normal part of provisioning a server. I haven’t seen the same thing with AppArmor (although I admit I have less visibility into debian systems administration). YMMV but it seems to me that a component which is so inconvenient that it’s normally disabled doesn’t provide much security in the end.
I was expecting to see something about how Debian's updates are slow. Instead I learned something about SELinux, which is cool. However, I don't think it's fair to extrapolate from this that Debian is less secure in general. A case has been made here that Debian is less secure for containers and server usage. For desktop users who just want sandboxed applications, I don't think Red Hat's SELinux implementation does much to protect them.<p>Sidenote: I don't like the implication that community-driven projects are inherently less secure.<p>> Lack of Resources: Debian as a community-driven project lacks the resources to develop and maintain comprehensive security policies comparable to those provided by Red Hat.
> Containers are increasingly the preferred method for developers to deploy their software – myself included. A common misconception is that if you run something in a container, it’s inherently secure. This is absolutely not true. Containers by themselves do not solve a security problem. They solve a software distribution problem. They give a false impression of security to those that run them.<p>To the extent that containers are a software distribution method outside of a single authority, they are a security nightmare. They are the exact equivalent of shipping a developer's laptop off to the datacenter and replicating it as a production image.
Wait, the author is criticizing Debian for not having as heavy-handed a system as SELinux enabled out of the box? That thing that causes so much pain that everyone disables it immediately unless they have fairly extreme security needs?
I fell in love with this article at this sentence:<p>> Still. Many in the open source community have interpreted Red Hat’s decision for what it really was: A dick move.<p>I've had a short essay in draft for a while about the difficulty of a small business trying to make money using The Red Hat Model (<a href="https://opencoreventures.com/blog/2023-04-red-hat-model-only-worked-red-hat/" rel="nofollow">https://opencoreventures.com/blog/2023-04-red-hat-model-only...</a>). Red Hat seem like an outlier who're doing well with that model, but smaller places like Sidero or Bitfield had to find other ways to monetise their open source efforts, and sometimes that had pushback from the community.<p>Red Hat, though, were acquired by IBM, and IBM made it harder for an otherwise thriving ecosystem to exist. Not impossible, but harder. IBM makes money hand over fist (billions according to <a href="https://www.ibm.com/annualreport/" rel="nofollow">https://www.ibm.com/annualreport/</a>). Was there really a reason to make Red Hat harder to redistribute? The interviews I've read come down to "our Red Hat team works hard and we don't want to give that away to low effort projects", though if you've got an interview with a different perspective I'd love to read it.
> Lack of Resources: Debian as a community-driven project lacks the resources to develop and maintain comprehensive security policies comparable to those provided by Red Hat.<p>And Linux in general has less resources to develop and maintain comprehensive security policies comparable to those provided by Microsoft.<p>Yet here we are, with Microsoft products so "secure" that they're insecure unless you have a PHd in b****, being so convoluted and over-built that people have to migrate away from it just to recover the actual security they used to enjoy back when they were able to wrap their head around the whole stack.<p>If devs want things to be more secure, stop developing more acronyms and just educate the userbase on the acronyms they already have.
To be honest the never ending headache of getting things to work with SELinux under RHEL was a big driver for why I moved to debian.<p>Certainly SELinux has its place but I never found the value it offers to be worth the complexity it adds.
1. You can enable SELinux on debian if you want to.
2. I've never had a conversation with anyone who is enthusiastic about SELinux.
3. I've never run into someone who was good at explaining SELinux policies, how to create them, update them, or explain their decision process other than "well... the app seems to need to do x, so we should let it."
4. I have run into plenty of people that disable SELinux out of the gate to avoid the headache of it.
5. I have run into plenty of people that avoid Redhat distros.<p>This is akin to someone writing an article about how Oracle and Microsoft got databases wrong because they didn't embrace some security feature that only DB2 has and that more than half of DB2 users out there think is a giant pain in the neck.
SELinux Coloring Book PDF, <a href="https://developers.redhat.com/e-books/selinux-coloring-book" rel="nofollow">https://developers.redhat.com/e-books/selinux-coloring-book</a> & <a href="https://people.redhat.com/duffy/selinux/selinux-coloring-book_A4-Stapled.pdf" rel="nofollow">https://people.redhat.com/duffy/selinux/selinux-coloring-boo...</a><p><i>> Learn the basics of SELinux, including type enforcement, Multi-Category Security (MCS) Enforcement, and Multi-Level Security (MLS) Enforcement, with the help of some friendly cats and dogs!</i>
Be interesting to know if anyone had any numbers on actual security issues in practise.<p>Complexity is generally really bad for security. It results in people working around the system or just turning it off. Security is not just "in theory" - a perfectly secure system that most users disable is an insecure system.<p>It reminds me a bit of the idea of making people change their password every month. Sure, in theory it reduces time a compromised credential can be abused for. In practise though it means nobody can remember their password, people start using really poor passwords and writing them down on post it notes. The net result is much worse security practically speaking, even if its better theoretically.
Debian can run with SELinux if you like that.<p>Debian uses AppArmor by default, probably because of the Canonical influence (there are more Debian developers and maintainers paid by Canonical than by RedHat).<p>But you can run Debian with SELinux (as well as with other LSMs, MACs, etc like Tomoyo).<p>At my last jobs, we disabled any of SELinux, AppArmor and Auditd on Debian/Ubuntu, just for the sake of performance. And we never detected any security issue for our usage and requirements. So I'm not an expert in this field.<p>Not sure what the purpose of the article, or the whole blog, is. You want to influence the choosing of Debian Vs RHEL Vs Oracle Linux in some place? As I'm not sure, will stop here.
I came in expecting not to, but I completely agree with this article. I moved off RHEL after using CentOS exclusively for a decade because of the changes in 2023. I loved SELinux, it's a technology you need to sink your teeth into if you want to understand it, but it has decent tooling (like audit2why) and isn't too hard to modify to get working if needed (SELinux booleans are a powerful way to modify base policies without having to recompile).<p>I do a lot in Kubernetes, and there's been more than one CVE with a line like "Affects all versions of docker/containerd, unless running SELinux," which gave me a lot of reassurance that the effort put into making SELinux work was worth it.<p>Now that I'm on Debian, I'm slowly building a new set of policies for the OS. Thankfully SELinux has an excellent reference policy[1] to base off of. I'm hoping my new debian base images for my homelab & elsewhere will have a nice restrictive default SELinux policy by the end of the year. I hope there's more community effort here as well, SELinux really can't compare to AppArmor, and is absolutely necessary for proper security.<p>Honestly I'd love if the wider community took another stab at replacing SELinux with a KSM that had similar functionality but better tooling and design. I'd pick it up in a heartbeat, but right now SELinux is what we have.<p>[1]: <a href="https://selinuxproject.org/page/NB_RefPolicy" rel="nofollow">https://selinuxproject.org/page/NB_RefPolicy</a>
This is a surprising article because I kind of see this in light of the old Linux/BSD wars?<p>“Red Hat owned making this policy apply to most of the popular software they distribute. On Debian the users have to set everything up.” — this sentiment is directly parallel to how BSDs see themselves as providing a whole consistent operating system, Linux meanwhile just wants to ship a kernel.<p>“Debian doesn't care enough about security.” — says everyone who runs OpenBSD.<p>“With SELinux policies, containers are isolated from the system.” — you could almost say they are “in jail,” maybe we could package this up as a syscall, hm, but what to call it...<p>IDK what BSD looks like in 2024, but in ~2004 you would have seen this exact same article about Debian, but comparing to FreeBSD instead of RHEL.
Excellent article. The key take-away for me is:<p>> The ugly truth is that security is hard. It’s tedious. Unpleasant. And requires a lot of work to get right.<p>I use Red Hat-based distributions at work and Debian/Ubuntu in my personal life. A few years ago, I bit the bullet and learned enough of SELinux to run my workstation and all my servers in <i>enforcing</i> mode. The author of this article is right to credit Red Hat for all the work they’ve done to provide users with default SELinux policies that work out of the box. At one time, I considered installing SELinux on my Debian system and modifying Red Hat’s policies to work with the Debian packages. I realised how much work would be involved so I chose the path of least resistance: AppArmor (which does the job).
Debian is a desktop operating system for human persons who are responsible for their computers. Red Hat is a enterprise operating system for corporate persons where the human persons using their computers are not responsible or in control of their computers. It's apples and oranges.<p>These aren't "attack surfaces left exposed" this is "users allowed to control their own computer and decide for themselves". And I notice the vast majority of this complaint about insecurity is not about running applications on Debian or RHEL, but instead about the systems built up for running things containerized and trying to mitigate all the problems that causes. Debian concentrates more on actually having an OS you can run applications on rather than a system for deploying containers.<p>>In the end, the choice between Debian and Red Hat isn’t just about corporate influence versus community-driven development. It’s also a choice between a system that assumes the best and one that prepares for the worst. Unfortunately in today’s highly connected world, pessimism is a necessity.<p>In the end it's about weather you think you should control your computer or weather someone else will control your computer. Pick appropriately for context.
SELinux is Mandatory Access Control system. MAC is not that useful for most servers:<p>The real risk comes from network-facing services and they are much better protected by seccomp and cgroups, usually configured in systemd, and Debian uses that extensively.<p>Seccomp can even protect vulnerable system calls. SELinux is not able to do that.
For systemd services, there's also the option to use the service unit directives that systemd provides to limit caps (CapabilityBoundingSet, NoNewPrivileges, etc), filesystem access (ProtectSystem, ReadWritePaths, etc), other "system" access (ProtectProc, PrivateUsers, RestrictNamespaces, etc) and syscalls (SystemCallFilter). I find these an easier and more direct way to harden than writing apparmor / selinux profiles.<p>`systemd-analyze security <service unit name>` gives a nice list of things to consider tweaking. You don't have to fix everything or pay attention to the exposure ratings, just use it as a guide.<p>I did this for chrony, haproxy, nginx, tor and unbound on my Debian router. I also have some timer units to run scripts to update DNS blocklists and such, which have the same kind of hardening. For the services, some of them have caveats and can't be fully hardened, eg unbound needs PrivateUsers=no because it fails if it can't find an unbound:unbound user to switch to, even if it was already started as unbound:unbound by systemd. And SystemCallFilter makes it easy to get overzealous and only allow the exact set of syscalls that you see the service making, only to have a service update or glibc update that starts making a new syscall and requires another round of debugging, so do it in moderation :)
With the sheer volume of local exploits found in the Linux kernel, I don't really consider these SELinux/AppArmor mitigations to be that useful. Sure, they reduce the attack surface a bit, but if I actually need isolation between workloads, it's best to do it below the kernel (with a VM).<p>If an attacker gets execution in userspace, it's best to assume they can also get into the kernel via some 0-day local privilege escalation...
I think that both AppArmor and SELinux are unusable in practice due to lack of better tools for generating those configurations.<p>There needs to be better graphical tools for this, like a "profiler" or similar that watches a process for a specific time for errors in the config and that incrementally adds features while the process is running.<p>In my opinion, systemd sandboxes are where it's at. [1] They are seccomp based sandboxes, but have a lot of isolation and sandboxing features that are very easy to use, and they can also be incrementally enhanced with both SELinux and AppArmor profiles.<p>[1] "man systemd.exec" or <a href="https://manpages.ubuntu.com/manpages/bionic/man5/systemd.exec.5.html" rel="nofollow">https://manpages.ubuntu.com/manpages/bionic/man5/systemd.exe...</a>
The discussion of container security is completely lacking any mention of userns remapping, which is an excellent container security feature that's extremely easy to enable and use compared with AppArmor/SELinux (and would work extremely well in parallel with them).<p>That way if someone does manage to break out of a container they have the privileges of a dummy user that doesn't exist on the host, so unless they are using a kernel exploit, they don't have any privileges to be able to do any damage.<p><a href="https://docs.docker.com/engine/security/userns-remap/" rel="nofollow">https://docs.docker.com/engine/security/userns-remap/</a>
I disabled selinux after learning about dontaudit rules and having them waste my time.<p>That's not to say on very specific systems that need to be hardened, I do enable selinux and am glad it's an option. And if I have to use a security layer, I take the object based selinux over the path based apparmor.
RHEL doesn’t have any indication as to how the contrib repositories work. SELinux might be nice, but it won’t have any impact if I install a malicious package. And yes, I need contrib as I need the ability to use graphical drivers and play proprietary formats.
For my personal machines, I have an early install <i>script</i> that turns SELinux off <i>and</i> makes the system boot with mitigations=off. <i>Personal</i> machine, behind my own firewall etc. I'd hate to be a system administrator, and despite my existing habits, this article convinces me that, if I was, I would try to actually understand SELinux.
I'm way more worried about how a compromised xz-utils made it past the package maintainer and into the Debian repos. Mitigating supply chain attack vectors like this seem like the bigger priority by far and low hanging fruit. I don't follow Debian leadership but haven't come across any reaction or policy change to address this from them?
If you care about security, consider the security-oriented Qubes OS relying on hardware virtualization and running everything in Debian and/or Fedora VMs: <a href="https://qubes-os.org" rel="nofollow">https://qubes-os.org</a>. My daily driver, can't recommend it enough.
I wonder if this article title is a deliberate reference to 'The Insecurity of OpenBSD' article which also addressed a lack of SELinux or similar systems.
Honestly? SELinux is a nice idea, practically obscene, like many others, Solaris RBAC a "so important security feature" essentially no one use for real to name another.<p>Today most security breaches came from crappy applications with an immense set of dependency put into production because someone want them, there is no protection for them, adding long and painful system stuff is only a way to have also badly configured systems.<p>Debian issues are more in a complex custom setup, preseed it's a nightmare compared to NixOS, which is much more important than SELinux, regularly disable on most deploys.
Meanwhile everyone agreed that the convenience of magic integration with browsers and other things was more critical than security, in the default config, for a <i>password manager</i> of all things, when debian changed the default keepassxc package to omit optional added attack surface plugins. Not unavailable, just not installed by the default.<p>I wonder how many people that agree with this nonsense position also agreed with the keepassxc nonsense position.
I've seen poorly implemented SELinux policies make a workstation unusable and fill up /var with audit.logs that are tens of gigs.<p>You have to do 100% coverage testing on whatever program you're using. (Good luck if you don't have the source code.) Otherwise, you don't have any guarantee that your program won't seemingly be killed randomly.<p>Good luck, x2, if you have some snake oil "endpoint security" that keeps overriding your SELinux policy changes.
Never used this. All my wealth is still mine. No one stole it. Two decades of Linux on the desktop. Some almost always on. If risk is lower than 1/2decades it's not worth learning. Insecure debian it is.
Would generation of SELinux policies be a good use case for LLMs?<p>"Generate a SELinux policy for daemon X. This daemon accesses it's config file in /etc and it's runtime data in /var/x. It listens on network. All other activities should be disabled"