IMO, it's because relying on filesystem labels and compiled policies (SELinux) ended up being a poor design choice vs defining the access in easy to understand policy files (AppArmor).
AppArmor is easier to understand because it is simply less restrictive, and in that way it is less effective solution. I would not call SELinux as poor design choice because of that. You can't do things with AppArmor that you can with SELinux.
You can make your security as granular as you like; but it's just like any other architecture in that you have to come up with good abstractions that make it usable. SElinux is simply poorly designed.
Its because Selinux wasn't really designed for "sysadmins" it was designed for "governments" or organizations that need to meet a specific level of security as a contractual/legal requirement. Selinux came out of the NSA and is based around the Trusted Systems Criteria / Common Criteria, aka the Rainbow Books. If you look at 'Trusted Solaris' (or IRIX, AIX) you'll see very similar systems.
Is this poor design or simply, not designed _for_you_?
I agree, its a royal pain to manage, and it might be overkill for a small shop trying to lock down their web server. Thankfully there are other solutions, and operating systems that may better fit your use cases.
Well put, so to rephrase: SELinux is not for most people and cooperation, therefore, it is sensible to just disable it, making RHEL less secure than Debian in practice.
Very much the wrong takeaway. SELinux is absolutely for people and corporations and has been for most of it's existence, and no, it doesn't make sense to disable it anymore than it makes sense to run as root because it's convenient.
If you are looking for a justification to excuse bad security practices, you won't find it in the origin story of SELinux.
Its very much for people who are trying to lock down their systems. Its also very much for people who want to meet the Common Criteria. It can be both. But for some people, its very much over kill.
I mean yeah. It's software designed for compliance. It's technically capable of any kind of restriction a bureaucrat might envision, so it's the best thing available for the kind of checkbox security needed in a regulated industry.
I find it enlightening to read what kinds of justifications the proponents of SElinux use. It's never about the quality of the software; it's about how there's more band-aid tooling to make it easier to work with, or about how it's not as bad as it was, or that it gives you all these knobs and levers to have more control. It's not what you focus on when you're serious about quality software engineering.
Imagine if we were talking about something like Gnome or the Windows 11 interface: yeah, the interface is a real pain to navigate, but we added even more menus and buttons and the rightclick menu is twice as long now, so you can do even more stuff with it, and we even added Clippy back in to help you when you get stuck!
Yes, SELinux is enormously complex and typically obtuse. However, it's difficult to imagine a much more "elegant" solution for the role SELinux serves. Linux, and Unices in general, are simply not designed for security. Indeed, the virtualization movement was largely driven by process isolation being so poor in mainstream operating systems.
SELinux is designed to fulfill to primary goals. First, to secure the messy and complicated Linux architecture. And second, to be flexible enough to accommodate (highly) complex security architectures, as well as potentially unique and/or unforeseen needs. With that in mind, it's difficult to imagine any equivalent being practically more simple and/or elegant than SELinux.
The primary problem with SELinux is the broad lack of experience amongst users and sysadmins, opaque documentation, and primitive tooling. And in many ways, it is a negative feedback loop. If SELinux was used everywhere, improvements to its documentation and tooling would naturally follow.
Some variants of Unix are designed for security; OpenBSD comes to mind. And Theo is on the record eviscerating the notion that virtualization be used as a security measure. Something about complexity being counterproductive to a secure system.
You're describing the linux architecture as messy and complicated, but that describes the SELinux architecture as well; if complexity & mess are bugs that should be squashed in pursuit of security, SELinux is ill-suited to the task.
> And second, to be flexible enough to accommodate (highly) complex security architectures, as well as potentially unique and/or unforeseen needs.
>> It's technically capable of any kind of restriction a bureaucrat might envision
Sounds like we're on the same page there. Or at least looking at the same phenomenon.
Your last paragraph is definitely outside the pattern of justifications I listed, but it's not much better: you're just blaming the users. Sysadmins use all kinds of complex software to accomplish any number of delicate tasks - if the tool is well-built, they don't tend to complain that it isn't. SELinux is not. Don't blame the user when the tool's at fault.
And if you want to see something that is the pinnacle of design in this space, go no further than openbsd pledge and unveil. Out of band policies is an ugly way of doing this.
Sorry, I was responding to the parent's question about why one was disabled over the other. Yes, SELinux is more capable, at the cost of additional complexity. I think it's debatable how many companies need that complexity, especially outside of the federal space.
I’d bet money the main practical purpose SELinux serves is to check boxes when negotiating government contracts, in a way that’s familiar and can be called a standard.
Then in practice someone ends up writing a couple policy statements and filing a couple forms then disabling it anyway, nearly every time.
If that’s the case it doesn’t need to actually work in practice, just hypothetically.
I've never seen SELinux as a requirement for any auditing, and I've done a fair amount of auditing.
It's not the only project like it, it's the one that is most well known because it has the NSA attached and because it got incorporated into the main kernel.
It works in practice, absolutely, but most people are too intimidated or lazy to put in the effort to learn it.
Having read the article I could not find any example of what is impossible in AppArmor, just a statement repeated in various ways that SELinux is easier to provide a secure-by-default environment with the closest thing to justification being that SELinux models things with types whereas app armor deals with restrictions on specific applications. I’m sure this all makes sense to someone already well-versed in the space, but I’m left with the same question as OP.
> I could not find any example of what is impossible in AppArmor,
AppArmor is simply less granular. For example, it doesn't provide true RBAC or MLS security models. It also uses paths instead of inodes, so a hard link can be used to override some policies.
So it just depends on what the exploit or attack is trying to do. If an attacker gets root and is trying to overwrite a file, they may be able to. Maybe they can't, but they could probably still execute any code they can write and compile themselves. And perhaps they can write to other files and do damage.
SELinux and similar systems allow a lot more granularity. Programs and users can only talk to explicit what they are allowed to talk to, and maybe you want to limit the access to say, append instead of full write access.
It just allows a lot more granularity and restriction, that's the difference.
I was surprised by his praise of MCS. We noticed it when reusing the same volume for subsequent reuse of a podman volume. It's a couple of years already, but it was not really explained in the documentation, only in a blog post by a RH emloyee. One weird thing is that the labels are random, but the range of possible values is rather small. So a determined attacker could brute force them. Also we always had a mix of files with and without MCS labels on the volume. IIRC moving or copying files led to different results. Not clear to me why a copy should be protected differently than a moved file, they seem of similar sensitivity to me.
It's been a while and we hacked around it, don't remember how. Except that it was not the #1 solution, disable SELinux altogether.
At least as far as the filesystem labels are concerned, the designers of SELinux consciously chose to use inode-based labels instead of path-based policies because the latter can be dodged via hard links. For this reason, it's best to disallow hard linking when using AppArmor, while such a restriction is unnecessary under SELinux.