[CrLf]

SELinux suffers from a reputation problem. It gained that reputation early on, while default policies were still very immature and overly restrictive.

One crucial change for the better was leaving third-party software in a permissive state. From that point onwards, disabling SELinux is cargo-cult sysadmin'ing.

SELinux is not hard if you understand its basic principles. But no one bothers, because SELinux is the bogeyman.

Yes, writing policies means getting knee-deep in macros, and it's hard because many services try to access anything and everything. But almost no one needs to write a policy.

At most you need to tell SELinux that some non-default directory should have some label. That's not hard.

[noinsight]

> But almost no one needs to write a policy.

But that's exactly what I would like to do! I've never seen a real guide for how to set up a policy for a custom daemon I wrote myself. Or when a specific software doesn't come with a policy.

[CrLf]

It's true that there is a lack of simplified documentation. But that lack is also the result of the folks that would otherwise contribute to such documentation not even giving SELinux a chance.

Many years ago I decided to face the Bogeyman and went from knowing very little about SELinux to writing a policy from scratch in about a month. The policy is simple enough (but realistic) that it might help in the absence of a guide:

https://github.com/carlosefr/kyoto/tree/master/selinux

I used it as an example in a couple of talks, whose slides might also provide additional context:

https://github.com/carlosefr/public-talks/blob/master/presen...

[cesarb]

> At most you need to tell SELinux that some non-default directory should have some label. That's not hard.

In my experience, it's not just directory labels ("semanage fcontext -a -e ..." and friends). You also need once in a while to set some booleans ("semanage boolean ..."). Yes, it's not hard once you know about it.