SELinux In Linux 6.4 Removes Run-Time Disabling Support

[mether]

Presumably "sudo setenforce 0" will still work. Otherwise my local Apache is hosed...

setenforce doesn't disable SELinux. It temporarily sets SELinux to be permissive. That isn't impacted by this change which was enacted by Fedora years back. You also never need to put SELinux into permissive mode on the whole if you only want to disable it for Apache only. You can just run

semanage permissive -a httpd_t​

to set that to be run in permissive mode or

setsebool httpd_disable_trans 1​

which disables it for just Apache.

[Sethox]

Like everyone know, in the name of security you cannot have comfort. Meaning the end-user will end up finding less reason to use SELinux because of it's hard restrictions (to even this feature of real-time disable SELinux).

The SELinux use case will be refined further for special cases and not an entirely comfort-for-home use case (which in my honest opinion is a sad reality but ultimate good security).

[aviallon]

This is a short-sighted Linux-breaking feature to me. Surely the "genuis" authors of this change understand that the more code you have, especially code written by the NASA, the more bugs you have. Ideally we would increase security by removing this Googleware (spyware) but then where would the money to the authors go........

What the heck?

[NomadDemon]

Yeah... i have often found the Linux security model to be more about abusing the end user. At home or in the corporate environment! Its one of the major reasons why Linux is unable to break into the small business realm... it's just way to painful to try to do simple things around permissions, especially if you want to move data out of the default "package configured" directories.

More secure? Maybe... Deeply painful bordering on useless? 100%... (specifically wrt the non-cloud operators).

why? exaplain to me please, why would some soft want to use more than userspace?

[doublez13]

The security benefits that SELinux brings (especially to internet facing web servers) is well worth the day or two it takes to get a decent grasp on it.
The SELinux troubleshooting utilities today are leaps and bounds ahead of what they were 15 years ago. It's almost trivial to find the correct boolean to switch, or the correct type to set on a file.

That being said, this pull request doesn't make it any more difficult to disable. You change a line in a file...

[archkde]

This is a short-sighted Linux-breaking feature to me. Surely the "genuis" authors of this change understand that the more code you have, especially code written by the NASA, the more bugs you have. Ideally we would increase security by removing this Googleware (spyware) but then where would the money to the authors go........

First of all, SELinux was written by the NSA and not the NASA, and second, I'm not sure how you would remove the "Googleware" this time, since it already was a removal.

[piotr.dobrogost]

setenforce doesn't disable SELinux. It temporarily sets SELinux to be permissive. That isn't impacted by this change which was enacted by Fedora years back. You also never need to put SELinux into permissive mode on the whole if you only want to disable it for Apache only. You can just run

semanage permissive -a httpd_t​

to set that to be run in permissive mode or

setsebool httpd_disable_trans 1​

which disables it for just Apache.

Thanks for the valuable info but I can't help but smile when you first explain that setting permissive mode is not disabling SELinux and then proceed to set permissive mode for Apache as a way to disable SELinux for Apache

[mether]

Thanks for the valuable info but I can't help but smile when you first explain that setting permissive mode is not disabling SELinux and then proceed to set permissive mode for Apache as a way to disable SELinux for Apache

You are welcome. To be clear, I offered two different commands, the first one to set it permissive mode and the second one for disabling it. They aren't the same.

[Paradigm Shifter]

...set it permissive mode and the second one for disabling it. They aren't the same.

I've never quite understood this. To me, it appears to be a distinction without a difference. "Permissive" allows actions to be carried out which are normally denied when "enforcing". Disabling does the same thing (although with permissive mode it still logs?). If I'm running a distro with SELinux, I'd rather get contexts set appropriately (which was really, really fun (sarcasm) with trying to set up a TFTP bootserver, let me say...)

[mether]

I've never quite understood this. To me, it appears to be a distinction without a difference. "Permissive" allows actions to be carried out which are normally denied when "enforcing". Disabling does the same thing (although with permissive mode it still logs?)

My first post also has a link that explains the difference. Disabling means that you no longer have any SELinux contexts associated with any file operations you do after that point. This is why a full relabeling becomes essential if you ever decide to enable it again. Permissive however can be useful for debugging and for tweaking the policy. Setting it back to enforcing is much more targeted operation later. While in permissive mode, everything maintains all the contexts and audit logs shows exactly what what would have been denied if it was in enforcing mode. You can generate get hints on SELinux booleans (like the ones I showed in my first) or even custom policy from those logs using tools like sealert and audit2allow. For a gentle introduction, listen to this talk "Security-Enhanced Linux for mere mortals".