LWN: Comments on "OpenSUSE Tumbleweed switches to SELinux"

SELinux/AppArmor

PastyAndroid — Wed, 19 Feb 2025 14:36:53 +0000

I personally feel they both have a good set of pros and cons depending on your use case. For example; in a 'professional' setup for servers and such like, I'll take SELinux with a strict policy - it's important that the systems stay secure. That, and you always know (or should) what is running, what it should be doing and why, so making and maintaining your policies to match this is easier. So, for those systems I always go the SELinux route.

On the other hand, I tried SELinux on my personal Gentoo a couple of years ago.... it was just so much work for a simple desktop setup that in the end I threw in the towel and went AppArmor instead. I can make policies quickly and have things protected by within a few minutes. For a regular desktop setup AppArmor can be 'enough'.

So, really both have their pros and cons, in my view. So, I do hope that both continue to be maintained.

Simpler is usually more secure, but incentives are for complexity

raven667 — Tue, 18 Feb 2025 14:01:20 +0000

I think this is the best most succinct diagnosis of the downsides of SELinux that I've seen, that goes to the heart of _why_ crafting/auditing policy with it is hard for most people, although I don't think the cause is CISOs _trying_ to make things more complex as some sort of policy goal, my guess is that SELinux is well used enough on widely deployed systems with an ecosystem of log analysis and policy documentation around it that it's the "safe" option, it may not be the best for all cases but it has critical mass, which is often a larger consideration for long term maintenance. Maybe another theory can help explain its popularity along with its polarizing character.

SELinux is better for containers

DemiMarie — Mon, 17 Feb 2025 20:03:40 +0000

The problem is that containers generally have complete control over what the filesystem namespace looks like within the container.
SELinux doesn’t care about paths. It cares about labels, and those aren’t under container control.

SELinux is better for containers

cschaufler — Sun, 16 Feb 2025 22:40:58 +0000

MCS (multiple compartment security) is a minor component of SELinux, and you can't get it by itself. You have to accept all of the SELinux policy overhead to get MCS. Smack, on the other hand, supports compartments trivially, with much less other policy baggage. If MCS is really the only reason for you to use SELinux you may find it isn't your best alternative.

Ubuntu next?

jond — Sun, 16 Feb 2025 09:49:41 +0000

And Debian.

Ubuntu next?

jrjohansen — Sun, 16 Feb 2025 08:44:36 +0000

There is overlap, but each has elements that do not translate well to the other. So it will very much depend on what is being confined and what type of policy you are trying to achieve.

SELinux is better for containers

jrjohansen — Sun, 16 Feb 2025 08:40:47 +0000

With AppArmor you put each container into a different instance of a profile. It is closer to the udica approach.

SELinux is better for containers

DemiMarie — Sat, 15 Feb 2025 19:07:36 +0000

SELinux is a much better choice for containers because of MCS, which provides protection in the event a resource from one container gets leaked into another somehow.

Ubuntu next?

cschaufler — Sat, 15 Feb 2025 17:25:07 +0000

You would have to create an SELinux policy that covers not only the problem at hand, but all system resources. You would also have to add pathname based controls to SELinux. So no, you can't implement AppArmor controls with SELinux policy.

Ubuntu next?

jengelh — Sat, 15 Feb 2025 11:22:30 +0000

>There are many cases where the extreme fine grained controls of SELinux are not a good match for the problem at hand

If it's fine-grained, surely SELinux can represent AppArmor rules, and it's just a matter of someone writing a translator, is it not?

Ubuntu next?

Cyberax — Fri, 14 Feb 2025 17:36:44 +0000

Yes. Let's converge on the new standard: disabled SELinux.

Ubuntu next?

cschaufler — Fri, 14 Feb 2025 17:05:21 +0000

As the maintainer of a MAC enforcing LSM I am disappointed whenever a distribution goes into the SELinux camp. There are many cases where the extreme fine grained controls of SELinux are not a good match for the problem at hand. The other MAC implementations exist because of this. I understand that it would be convenient if there was only one MAC implementation, but then it would be convenient if there was one disk driver, one memory manager, one CPU architecture, one graphics implementation and so on.

Simpler is usually more secure, but incentives are for complexity

walex — Fri, 14 Feb 2025 11:50:42 +0000

The simpler a security-related system the better security because it is less likely to be misconfigured or even entirely disabled, and SELinux has the huge flaw that it operates at an abstract level above actual system resources, so requires extensive mappings between the two levels and requires a lot of maintenance and to understand what a configuration actually does is quite hard; instead AppArmor operates directly at the system resource level, so it is much easier to configure and to understand what a configuration does (even if AppArmor configurations on Ubuntu have become more complex with time). My impression is that SELinux adoption is driven by the incentives of corporate security officers to add complexity.

Ubuntu next?

lobachevsky — Fri, 14 Feb 2025 09:52:41 +0000

That leaves Ubuntu as the last one standing using Apparmor? Maybe all the big distros that use MAC can finally get behind a single thing.

Leap 16 already changed to SELinux

corbet — Thu, 13 Feb 2025 16:06:31 +0000

Apologies, that was confusing; I just tweaked the wording to make it clear that Leap 15 is not changing.

microOS derived openSUSE Distributions

SFalken — Thu, 13 Feb 2025 16:03:46 +0000

the microOS derived openSUSE Distributions have been SELinux Enforcing by default for a few years now. It's been pretty pain free.

Leap 16 already changed to SELinux

Conan_Kudo — Thu, 13 Feb 2025 15:37:05 +0000

This already was done for openSUSE Leap 16. It was done there first.