[d2mw]

One reason to dislike SELinux is the arbitrary assumptions baked in by default that barely anyone knows how to or cares to change, which makes carefully designed software look broken when the framework itself is broken. One example I've faced is UNIX pipes, which for all purposes were obsoleted by UNIX domain sockets in the mid 80s as part of the original intent of the BSD socket API, but to SELinux they are profoundly different things. You can pass pipes across a user->root boundary but not a socket.

To the end user, they only see your code broken by SELinux, and assume you haven't done your job. On the other hand, SELinux is codifying rules about UNIX that never existed and amount to emotional heuristics about the risk of Internet domain sockets being inherited around the system by the wrong process. The effect isn't to prevent Internet domain sockets being inherited by privileged processes, but breaking all sockets. That's garbage design, hidden behind marketing suggesting because the NSA contributed some code that the problem couldn't possibly be SELinux

[debatem1]

But unix domain sockets are not pipes, not least in the important way that you can reliably determine the identity of the other end. That can in some cases be an infoleak, and therefore needs independent access control.

[d2mw]

If SCM_CRED passing were a real problem in _any_ scenario, SELinux should target that instead, not an entire subsystem on which half the system is built

[debatem1]

The point is you need the ability to express both "these are the same thing" and "these are different". You can do both with SELinux. What's your alternative?