SELinux Continues Path Of Deprecating Run-Time Disabling

[RahulSundaram]

What about setenforce 0? I use that in my workflow to quickly create audit rules.

That doesn't disable SELinux, only sets it to permissive and isn't affected by this change.

[Britoid]

Yet another reason to abandon SELinux and switch to apparmour.

AppArmor doesn't even remotely cover to the same level as SELinux, SELinux is a dragon, AppArmor is a puppy.

That said, with rootless "containers" and namespaces, the usage of SELinux has changed. We can now shove a service in a container or locked namespace (e.g Systemd) and only use SELinux to ensure the service can't break out of that container (with rootless containers I think rare?)

[nanonyme]

That doesn't disable SELinux, only sets it to permissive and isn't affected by this change.

Right. And permissive unlike disabling does not actively break your SELinux setup over time. If you disable SELinux, you might end up needing to relabel entire hard disk.

[anarki2]

What about setenforce 0? I use that in my workflow to quickly create audit rules.

Use "permissive" for that.

[anarki2]

Yet another reason to abandon SELinux and switch to apparmour.

If you have absolutely no idea what you're talking about, then yes, this news might lead you to such conclusions.

[kloczek]

If you have absolutely no idea what you're talking about, then yes, this news might lead you to such conclusions.

Because?

[sarmad]

If SELinux was designed properly people wouldn't need to disable it at run time. But it's just over-complicated, making it easier to just disable it when testing stuff than wasting time trying to figure out how permissions can be given in SELinux.
SELinux is one of the reasons I stay away from Fedora.

[szymon_g]

What is the performance penalty of SELinux and does any Linux distribution ship with SELinux enabled by default?

afaik the penalty was of less than 1% and substancially lower than the penalty of Apparmor (which was a big surprise to me). AA has been fixed in ubuntu and suse long time ago.

[szymon_g]

If SELinux was designed properly people wouldn't need to disable it at run time. But it's just over-complicated, making it easier to just disable it when testing stuff than wasting time trying to figure out how permissions can be given in SELinux.
SELinux is one of the reasons I stay away from Fedora.

it was a while when i had to create a rule for selinux.
sure, 10 or 15 years ago it was hardly usable, but nowadays for most of the time one can forget that one uses it.

[emblemparade]

If SELinux was designed properly people wouldn't need to disable it at run time. But it's just over-complicated, making it easier to just disable it when testing stuff than wasting time trying to figure out how permissions can be given in SELinux.
SELinux is one of the reasons I stay away from Fedora.

It's definitely complex, but I strongly recommend every Linux user (especially admins) take some time to learn its basics. Just like various other Linux subsystems (filesystems, networking, systemd, etc.) there is a learning curve, but SELinux should be considered one of these essential subsystems. The complexity comes with a robust, flexible, and finegrained implementation that can secure many parts of the OS. That said, I do wish there were more and better tutorials out there. Learning it was not so trivial for me, but I'm very glad I took the time.

Fedora is a workstation OS -- it's called Fedora Workstation, after all -- so it does intend to out-of-the-box have a solid server-like environment. If you don't care about industry-grade security you might possibly be served better by other distros. Or, if you want Fedora but without heightened security, it's not hard to disable SELinux entirely.