Egregoros

@kirby @rl_dane Anyone that used SELinux on a distro properly supporting it for more than an hour knows that it is unusable for non-server use because everything outside the system package manager gets blocked in multiple ways. No single user will be writing SELinux policies to get stuff they compiled from source working correctly.

And AppArmor is utterly useless as without a policy it does exactly nothing.

Not to mention that they both are optional security features and optional security can be turned off.

@fedops @kirby @rl_dane It isn't unless you want your desktop computer to work like a phone, I certainly don't.

It works on Android because the runtime enforces its own permissions in an app sandbox with the Android permission system and SELinux sandboxes the rest. And I don't want my computer to turn into a sandboxed-by-default environment either.

The users are right in disabling SELinux or turning it into a permissive state, because very few actually know how to write the policies properly. There is no usable documentation on how to do so besides Red Hat's own paid courses and the already existing policies. If you put a binary into /opt/bin, start it with a systemd service and run the audit2allow commands SETroubleshoot recommends, you are giving those permissions to systemd (init_t), not the actual service.

Before turning to these rather drastic solutions like app sandboxing (snap, flatpak, etc.), it's much better to give the developers of those apps the abilities to declare what their own app is supposed to do and what it isn't supposed to do. OpenBSD realized this a decade ago with pledge. Throw away seccomp, implement pledge in the kernel and you have a much friendlier solution that doesn't annoy 99% of people using it. Landlock can stay.