[chunkyks]

Things may have changed, but the last few times I looked, it was breathtakingly hard to a) identify if /when selinux is what's screwing you, then b) get selinux to stop it.

I really wanted an audit mode that could also say "this command will unlock the specific thing I just blocked".

That was a few years ago. Since then, I've turned off selinux whenever I'm getting screwed by some opaque process, stuff starts working, and closing it back down while leaving what I need open remains impossible black magic.

[chucky_z]

Is audit2allow the thing you want?

[loudmax]

Probably yes, but audit2allow is very hard to reason about. You can run it and hopefully it will enable you to allow the things you want to allow without also allowing things you didn't want.

Red Hat doesn't seem to have any interest in making SELinux more accessible than programming in assembly. The UX for the tooling around SELinux is an absolute dumpster fire.

[mhitza]

On server environment that command is most of the time not installed by default.

Quick! tell me which package I need to install to get audit2allow on a system; without using Google, dnf whatprovides, or repoquery --whatprovides.

I'm still baffled why such an essential tool for quickly assessing violations and potential selinux booleans quick fixes is part of a obsfucated package name. I think some setroubleshoot family of tools might be installed by default on some systems, even if most answers will guide people to just use audit2allow.

[chunkyks]

I recall taking a stab at audit2allow a few years ago, and finding that it was incredibly opaque and felt like practising dark arts.

At this point, it's probably true that I should get onboard the SELinux train and learn it properly, but it's just... ain't nobody got time for that.

[chucky_z]

I believe this is considered one of the best videos: https://www.youtube.com/watch?v=_WOKRaM-HI4