[bravetraveler]

I know it's a hard sell, but the 30 minutes to an hour to understand filesystem contexts and how to copy them from a good place isn't a lot

It'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

[sph]

I have been doing Linux sysadmin for 20 years and I just stopped trying to understand SELinux. It looks and feels like an abomination borne out of some IBM or other antediluvian corporate UNIX system for programmers wearing suit and tie.

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.

[Anarch157a]

It was originaly developed by the NSA, so it's even worse than corpos wearing suit and tie, it came from spooks.

[voidfunc]

Probably intentionally complex for just that reason. Easy to leave a misconfiguration.

[bravetraveler]

I totally get it. I exert next to zero effort to keep it around for my systems!

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

[Modified3019]

>understand filesystem contexts and how to copy them from a good place

I’m not really sure what this means (I have 0 knowledge on selinux)

[bravetraveler]

edit: Apologies for the wall. I think I finally landed on a decent mix after many edits. I'm finished now, lol.

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

[Modified3019]

Very enlightening, I really appreciate the time you took to outline all of this, thank you!

[bravetraveler]

Some secondary reading, I've referred to FHS at times. It's the 'Filesystem Hierarchy Standard':

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.