How do you know when you’re letting through a valid access, an unnecessary one that could be a vulnerability, and an actively malicious one?
I don’t think anyone is saying throw out all access control, they’re just saying SELinux adds too much unproductive friction for everyday usage. You said it takes 15m to troubleshoot. But that’s not a one time thing, that’s 15m that scales with the amount of new programs and updates you’re running. And 90% of people aren’t even going to be able to tell they’re looking at a malicious access if they’re in the habit of always working around blocks that show up.
I would go a step further and say that any time one of these MAC systems has to resort to user interaction to do its job, it’s a straight up failure case: the system simply didn’t have enough information to do its job, ended up doing no better than a blanket “block everything” config, and is asking the user to do 100% of the heavy lifting of determining what should happen.
So, when I hear
I hear: “every access control system is fundamentally broken”. Which is fine, maybe that’s true, there’s a reason social engineering is so useful. So then all these systems should prioritize streamlining that failure case as much as possible: Tell the user what is accessing what, when, how, and then make it trivial to temporarily (with well defined limits), permanently, (or even volatile-y using CoW/containerization/overlay fs) grant or deny access as quickly and easily as possible.
Every other system you’re comparing SELinux, AFAIK, handles this case better, which is why users tend to prefer them.
For the record, I’m not arguing that SELinux is bad at the actual access control part, I’m only answering why people don’t like using it, which is how it handles the failure case part. Now it’s been a while since I’ve used SELinux and I’ve never used setroubleshooter, but if you tell me it actually streamlines all of this to be smoother than every other tool, then I’ll install it tonight!