I feel obligated to say that you should set it to permissive mode, never disable SElinux.
sudo setenforce 0It's likely to little gain. I know why people don't, but it is very accessible to those open to it
The more one adheres to the FHS, the easier SELinux is
Terrible documentation, terrible mental model, terrible CLI UX, terrible error messages.
I run Fedora and SELinux is working well enough, but it's a piece of machinery I can't wait to see replaced, however useful people swear it is.
For systems that shouldn't do much more than exactly what is prescribed, it's acceptable, is what I'm after... I guess.
I can't do justice to the source, but there's a concept about our programs/creations reflecting us.
Like a peer hints - SELinux reflects an agency like the NSA, draconian. Good and bad
I’m not really sure what this means (I have 0 knowledge on selinux)
SELinux has a bit of a well deserved reputation... but I, a fairly silly person, have managed to work with it
This video likely explains things far better than I can in this post:
https://www.youtube.com/watch?v=_WOKRaM-HI4
I'll probably fail with specifics, where they certainly do a better job.
So. First it's important to know SELinux runs in one of two modes:
* A targeted mode where well-known/accounted-for things are protected. For example, nginx
* A more draconian mode where *everything* is protected
People often present the first [default] mode as if it were the second.The protection is based on policies that say 'things with this label/at this path are allowed to do XYZ'.
It's very focused on filesystem paths and what relevant applications try to do.
It's entirely manageable, but admittedly, complicated. Without practicing the words I can't express them.
Most people having trouble with SELinux are defying some convention. For example: placing application scratch data in '/etc'.
Policy management is a complicated topic.
The policy can be amended in cases where the standard doesn't apply; I won't cast judgement - sometimes it's a good idea, sometimes not.
Another way to handle this is to copy the label from one path and apply it to the one your application requires/customizes. This is less durable than leaning on the policy.
It acts as a sort of central DB... the goal is to make things such that the policy stores all of the contexts so the files/dirs can have "labels" applied for SELinux
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
They provide guidance on how a given filesystem path should be used.
This has informed the default SELinux policies greatly; familiarity turns hassle into informed assumptions/ease.
SELINUX=permissive