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
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:
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