This is not a troll post. I’m genuinely confused as to why SELinux gets so much of hate. I have to say, I feel that it’s a fairly robust system. The times when I had issues with it, I created a custom policy in the relevant directory and things were fixed. Maybe a couple of modules here and there at the most. It took me about 15 minutes max to figure out what permissions were being blocked and copy the commands from. Red Hat’s guide.

So yeah, why do we hate SELinux?

  • DigitalDilemma@lemmy.mlEnglish
    51·
    20 hours ago

    I have a saying, “If it’s not DNS, then it’s Selinux”. It blocks stuff so frequently it’s a major time sink for us.

    It is overly complex and difficult to understand, especially if you’re developing and deploying software that does not have correct pre-rolled policies. A regular job for me is to help developers solve this - which generally means running their service, seeing what Selinux blocks on, and then applying a fix. Repeat 2-8 times until every way Selinux is trying to access a file is explicitly allowed. And sometimes, even software that comes via official repos has buggy selinux policies that break things.

    Fortunately, there are tools to help you. Install setroubleshooter amd when something doesn’t work, “grep seal /var/log/messages” and if it’s selinux causing the problem, you’ll find instructions showing you what went wrong and how to create an exception. I absolutely consider this tool essential when using any system with selinux enabled.

    • med@sh.itjust.works
      2·
      9 hours ago

      Is it not possible to run it in audit mode in dev and have it tell you what the would have blocked?

      • DigitalDilemma@lemmy.mlEnglish
        1·
        4 hours ago

        Permissive mode, and yes, you absolutely can. That shows warnings but doesn’t actively block. But you still benefit from running setroubleshoot to actually figure out what and why it’s blocked something, and how to mitigate that.

        Permissive is also good in that you can get a bunch of blocks reported at once, instead of having to step through one at a time, which can be useful.

    • marauding_gibberish142@lemmy.dbzer0.comOPEnglish
      3·
      12 hours ago

      Exactly. I use setroubleshoot myself and it’s awesome.

      I agree that creating custom policies for a bunch of apps day in day out will be tiring. But that is an argument against all MAC. I personally don’t want to see Linux going the way of abandoning MAC

      • teawrecks@sopuli.xyz
        4·
        9 hours ago

        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.

        • DigitalDilemma@lemmy.mlEnglish
          1·
          4 hours ago

          I think you make a good point, but it’s one that affects any anti-malicious protection. How do you know that the anti-virus warning you get on Windows is legitimate and not a false alert? Or that the Apparmor block wasn’t a misfire? Selinux is no better nor worse in principle than those.

          In all cases, you need to stop and figure out what’s actually going on. That’s one benefit of all these things - they make you pause and, hopefully, think, when something is outside the norm.

          And yep, they can be bypassed and they need to be able to be bypassed. If someone is lazy or not knowledgeable enough to make the right decision, or even just in a hurry, then they are at risk. No automated system can protect entirely against that.

          • teawrecks@sopuli.xyz
            1·
            3 hours ago

            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

            If someone is lazy or not knowledgeable enough to make the right decision…No automated system can protect [them].

            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!