Title.

  • comfy@lemmy.ml
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    9 hours ago

    Excessive for my threat model, one more thing which could break something (even if by no fault of its own).

    I like it, but many of my devices don’t use it.

  • deadbeef79000@lemmy.nz
    link
    fedilink
    arrow-up
    7
    ·
    13 hours ago

    It surprises me. Rather it’s not SELinux it’s userland stuff that reports the wrong error.

    Say I try to mount a directory into a podman container and try to read a file. I get some variety of file not found (it’s right there, I can see it) or permission denied error (its permissions are 777) but in reality its label is wrong.

  • wulrus@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    12 hours ago

    For 2 years, I had to set up production environments on RHEL, mostly Apache and Keycloak servers. I had a limited, very specific list of sudo permissions, and I had to ask very specifically what I else needed, which was then granted by people who neither knew nor cared what I was working on.

    SELinux permission problems were always the fallback reason when nothing else made sense. With my permissions, I could not just straight up check for it. E. g. Apache would not server a folder, cryptic error -> check file permissions -> check general Apache config problems -> assume SELinux permission is missing and request it, supplying the exact command they need to type.

  • moonpiedumplings@programming.dev
    link
    fedilink
    English
    arrow-up
    20
    ·
    1 day ago
    1. It’s extraordinarily complex.

    The reality is that security is not just technical implementation, but also actually getting people to use the solutions. “Stop disabling SELinux” is not a real answer to when people disable it, like we have one person in this thread.

    Another problem with complex security solutions is they are hard to get right. Even if you enable them and configure them, without being an expert, it’s possible you left a gap here or there, and holes and gaps in these solutions.*

    1. Like so many other complex linux security solutions, it is lacking effectiveness due to still sharing the same kernel.

    There is a good, but bit dated writeup here about the problems with Linux security, from an architecturual perspective: https://madaidans-insecurities.github.io/linux.html . But, the short version is that the Linux kernel is large and complex, and has a lot of attack surface. And it’s a frequent source of vulnerabilities because attackers can hit it as long as they access to the kernel, even if they are in a container/sandbox. Like, copyfail and dirtyfrag would punch through containers, but also punch through SELinux.

    For example, just earlier on lemmy someone dropped a zero day that punches through SELinux: https://programming.dev/post/51103657

    Now, SELinux can be used to restrict what a root shell could do after escalating… but that’s further complexity you have to learn to configure, and configure it correctly as well.

    Ultimately, none of the Linux security solutions come anywhere near the isolation of simply running something in a virtual machine. Which, also happens to be a lot simpler and actually possible to get people to use.

    *(putting this at the bottom because it veers off topic) I have a greater argument and problem with mentalities like this. I have noticed a pattern, where many of the more effortfull and toil intensive security solutions are recommended by people who have the time, energy, and skills to execute them. They have a bias/blindspot to the realities, which is that not everyone is in the same situation as them.

    For example, updating/patching software. Linux distros like RHEL or Debian, have a policy where they only do security updates, and don’t do feature updates or bugfixes. This enables them to ship automatic updates, so that security issues are automatically handled.

    On the other hand software like Windows, likes to bundle in breaking changes along with security updates. So automatic updates get disabled because “They might break something”. And then, people don’t update them, and environments get horrifically out of date, because not enough money/time/people is put into regular IT people who are in charge of maintaining them.

    But some environments, have heroes, people who go around patching everything and keeping everything up to date and secure. And when they see these environments that don’t have everything patched, they usually give the advice of “You should patch everything” (while simultaneously advising against auto updates), not understanding that these environments are lacking a key ingredient: Themselves.

    Sure, I could be a hero. I could “patch” everything manually. I could deploy SELinux. But that would only last until I get burnt out, or leave. Once I’m gone, SELinux, the patches, any similar security solutions are gone. I’ve met so many people, even in cybersecurity, that are apathetic about security, even though they might have cared once upon a time.

    • InnerScientist@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      10 hours ago

      Small correction:

      Like, copyfail and dirtyfrag would punch through containers, but also punch through SELinux.

      User namespaces and optionally limited capabilities severely limit the usefulness of both of these exploits. K8s containers with user namespaces or rootless podman prevent host-root and only allow elevating to container root (host uid != 0) and cross container cache pollution (jump to other containers that use the same base image?)

      • moonpiedumplings@programming.dev
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        2 hours ago

        Kind of.

        Copyfail would punch through user namespaces to get root straight on the host. User namespaces only really protect you against vulnerabilities in non kernel applications.

        Limited capibilities/seccomp policies did help, though. In my admittedly limited testing, some of the vulnerabilities wouldn’t work in podman, but they would work in docker. This wasn’t due to user namespaces, but this was due to podman having stricter capibilities/seccomp policies than docker by default.

        This implies that even if you were using docker rootless, they still would have been able to break out and get root in one go.

        User namespaces don’t add that much security, in my opinion. Assuming your container has a non root user inside, adding user namespaces just changes the amount of cve’s/zerodays from 2 to maybe 3:

        With a rootful container it’s:

        • Escalate to root (can be done after or before container escape)
        • Escape container (can be done after or before escalation to root)

        With user namespaces it becomes:

        • Maybe escalate to root within the container first to get privileges or access to binaries needed to take advantage of a container escape exploit
        • Escape container
        • Escalate to root

        User namespaces are like every other Linux security solution, they are extremely complex, hard to configure, and they don’t actually add that much security for the trouble The article I linked above has a section about them:

        Another example of these features is user namespaces. User namespaces allow unprivileged users to interact with lots of kernel code that is normally reserved for the root user. It adds a massive amount of networking, mount, etc. functionality as new attack surface. It has also been the cause of numerous privilege escalation vulnerabilities, which is why many distributions, such as Debian, had started to restrict access to this functionality by default

        Their complexity makes them difficult to secure and execute properly, and adds a ton of attack surface to the kernel.

        Dirty frag, for example, was using user namespaces as one of the ways it would escalate. Most container runtimes restrict user namespace creation within user namespaced containers (via seccomp/capabilities), so running dirtyfrag in a container wouldn’t have worked. But, at the same time, dirtyfrag is only possible in the first place because of the attack surface user namespaces cause.

        I mostly use docker and rootfull podman for everything. You already need a CVE/zeroday to do a container break out in the first place, so just keep your runtimes up to date and you should be good. If you really care about being proactive with security, and trying to preemptively prevent issues, user namespaces are not really a good solution, better is just to use a VM container runtime like kata or microvm, or a userspace kernel like gvisor or syd. They are pretty easy to use. You can just set them as your container runtime, in docker, podman, or kubes, and things will mostly just work. Those (and other kernel isolation solutions) would have actually beaten dirtyfrag, copyfail, and the like of recent vulns.

  • psycotica0@lemmy.ca
    link
    fedilink
    arrow-up
    32
    ·
    1 day ago

    I’ve encountered it very little, but when I encounter it it’s because I try to do something and it doesn’t work. So I check the permissions with ls -l, and it all seems reasonable. Huh, this should work. Try again, nope. Hmm. 20 minutes of trying random variations, strange results. Oh fuck, is this SELinux? Shit. Where do those configs exist again? How do I configure that? Google “SELinux cheat sheet” hmmm, I don’t have enough context to use that, Google “SELinux getting started”. Read tutorial, try to skim just enough to figure out what’s going wrong for me.

    So I don’t hate it, I just haven’t ever had a use for it, but it has surprised me in a bad way before and cost me a lot of time and confusion, but I’ve never spent the time getting familiar because I’ve never had a use for it. And it comes up rarely enough I never remember anything about it by the time it bites me. I can’t even recall now what I was trying to do the last time I bumped into it.

    • corsicanguppy@lemmy.ca
      link
      fedilink
      English
      arrow-up
      5
      ·
      edit-2
      1 day ago

      Absolutely this.

      33 years in Linux, 30+ professionally, Unix+Linux security background in a past life at a fucking distro.

      When I first install a new distro version, I do something very simple; maybe I configure a simple web page, for instance.

      Usually the web server refuses to start, or something equally “so dumb it should have been seen in early testing and doesn’t even get to the challenge I set before it” stupid. If the distro can’t test something so basic, then I know they’re not prepared to consider selinux implications while maintaining or debugging the distro. I don’t need to blaze a trail the distro can’t be arsed to.

      Then I mod away the config in my template and hope the distro can pull out their proverbial head in 5 years.

      The easiest path needs to be the safest path

  • atzanteol@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    15
    ·
    1 day ago

    It’s awesome, but very complicated to use and overkill for most homegamer setups.

    The first interaction most people have with it is when it stops something they want to do from working and it’s not obvious why. Then the first selinux command they learn is how to disable it.

  • Soot [any]@hexbear.net
    link
    fedilink
    English
    arrow-up
    17
    ·
    edit-2
    1 day ago

    Linux permissions are obvious, straightforward, and very easy to change - They rule.

    SELinux permissions are impossible to see, seemingly pointlessly more complex, and I don’t know how to check them or change them i.e. They drool.

    As a power user who is constantly changing system stuff, installing weird stuff, running weird servers, disabling SELinux is like, step 2 of installing Linux for me (and honestly, even if you’re not a power user, I can assure you at least ONE issue you’ve faced was actually caused by SELinux under the hood). I have wasted whole days working out just that SELinux is causing my fucking issue, and then days more on how to fix the permissions, and then days more doing those again when those permissions RESET as it is wont to do and days more trying to make my needed changes permanent. And let’s not even get started on how to transplant an SELinux permissions structure from one disk to another. So instead of a week’s worth of frustrating work every year, I can spend one minute disabling SELinux.

    Its implementation feels contradictory to the most basic principles of understandable and workable systems. It’s like the NSA wanted to make software that was the diametric opposite of the Zen of Python. It’s ugly, it’s implicit, it’s complicated, nested, dense, unreadable, full of special cases, and silent errors, it constantly guesses in the face of ambiguity (which is why I have to constantly correct it).

    Basically, I have wasted too much of my life faffing with an opaque and ludicrously complex permissions layer that seems to be there solely as a ‘just in case’ my already existing permissions aren’t good enough.

      • Soot [any]@hexbear.net
        link
        fedilink
        English
        arrow-up
        3
        ·
        edit-2
        21 hours ago

        If you’re just doing normal sheet, you should ideally basically not even notice SELinux. And in that sense it’s good.

        If you’re doing any dev or running any server software or some kind of freaky setup, my advice is disable it. At least all you have to do is turn a true into a false.

  • kureta@lemmy.ml
    link
    fedilink
    arrow-up
    30
    arrow-down
    3
    ·
    2 days ago

    It’s an unnecessary layer of complexity. I am the only user of my personal laptop. I don’t need fine-grained permissions. Linux users and groups are enough for any permission needs I might have, like docker group, audio and video groups, etc. I don’t have any “classified” documents on my computer. My home directory and root are on different disks. I can easily format and reinstall my system if something goes wrong and keep all my personal data.

    • custard_swollower@lemmy.world
      link
      fedilink
      arrow-up
      8
      ·
      1 day ago

      You don’t have classified documents, but you probably use bank in your browser running as your user. Maybe you use local mail program to send emails, also running as your user. A simple malware could add emails to be send asking your family to send you some money through online service.

      And that’s easily done because the only isolation layer is user and group.

      • nyan@sh.itjust.works
        link
        fedilink
        arrow-up
        2
        ·
        1 day ago

        Not everyone does online banking (I don’t), and it’s possible to warn your family about scams. If the information isn’t there, you don’t need to lock it down. Of course, that just moves both the security and the accompanying inconvenience off the computer and into the real world.

      • kureta@lemmy.ml
        link
        fedilink
        arrow-up
        2
        arrow-down
        4
        ·
        1 day ago

        I really don’t see how anyone can install malware on my computer. I know my way around computers enough to not do anything dumb. Of course if someone wanted, they would be able to hack my device, probably. But I am not a high value target and it would be a waste of their time and effort. In short, that’s a risk I am willing to take :)

          • kureta@lemmy.ml
            link
            fedilink
            arrow-up
            1
            arrow-down
            2
            ·
            1 day ago

            Yes. That’s fair. It’s an actual, realistic threat. But personally, I don’t provide any services to anyone and my data is periodically backed up to my NAS and cloud. But that’s me. I can imagine other scenarios that would definitely require SELinux.

            • atzanteol@sh.itjust.works
              link
              fedilink
              English
              arrow-up
              3
              ·
              23 hours ago

              Your data can be encrypted with a ransomware attack. Including your backups. Your memory searched for browser cached passwords and account names.

              You’re not with the effort? The effort is practically 0 these days. Bots written by AI don’t care. And your compute resources can be used to do more harm.

        • Yoddel_Hickory@piefed.ca
          link
          fedilink
          English
          arrow-up
          7
          ·
          1 day ago

          So you think NONE of the software you use will ever get an exploit? “Not do anything dumb” only covers some threats, not all.

          • kureta@lemmy.ml
            link
            fedilink
            arrow-up
            1
            arrow-down
            1
            ·
            1 day ago

            No. I mean why wouild anyone target me? I am behind my home router most of the time, without any exposed ports. I am not saying “SELinux is unnecessary”. The post asked for my reasons to dislike.

    • papercut@lemmy.ml
      link
      fedilink
      arrow-up
      6
      ·
      1 day ago

      Having your home directory on a different disk is something that could’ve saved me a lot of headache. Can’t believe I didn’t think of that.

      • Soot [any]@hexbear.net
        link
        fedilink
        English
        arrow-up
        4
        ·
        edit-2
        1 day ago

        In a lot of distros at least, you can just reinstall in place, which has the same effect. But a different place for /home does feel a potentially more reliable method.

        • atzanteol@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          2
          ·
          24 hours ago

          It used to be. I think it changed at some point to make installs easier for new people who were used to only having a single C:.

  • swelter_spark@reddthat.com
    link
    fedilink
    English
    arrow-up
    1
    ·
    19 hours ago

    I’m more familiar with AppArmor, and my distro’s forum gives the impression that switching involves a lot of configuration to get things working as expected…which, AppArmor did too, but I’ve done that already. Next time I install, I might try SELinux.

  • fartsparkles@lemmy.world
    link
    fedilink
    arrow-up
    18
    ·
    edit-2
    1 day ago

    If you’re mandated or regulated to implement MLS or MAC etc, SELinux is a security control that enables you to comply through expanded and expressive policy controls.

    When I hear dislike for it, it’s usually because people are using SELinux as a “make my personal computer safer” tool rather than the “we’ve hundreds of thousands of differently classified sensitive documents and thousands of employees with different clearances”.

    MAC/DAC/MLS isn’t designed for personal computing and if you think SELinux is the solution you personally need, you might need to reevaluate your threat model (as any external actor will seek to bypass kernel controls entirely e.g. CVE-2025-0078).

  • fozid@feddit.uk
    link
    fedilink
    arrow-up
    13
    ·
    2 days ago

    I don’t dislike it. I have no opinion on it. It’s something I have never looked into heavily enough as it has never been a potential solution to a problem I may have encountered. There are no security or hardening areas that I currently class as gaps that need plugging in any of my systems where I would consider looking into selinux.

  • hendrik@palaver.p3x.de
    link
    fedilink
    English
    arrow-up
    11
    ·
    2 days ago

    Uh. I guess people have random opinions and blast them on the internet. I can see how someone would misconfigure their computer and then blame it on the software. Or use software they don’t need, which just adds unnecessary complexity and more issues. Other than that, I don’t think there’s anything wrong with SELinux.

  • ISolox@lemmy.world
    link
    fedilink
    arrow-up
    5
    ·
    1 day ago

    After switching between distros for 8+ years and settling on Fedora KDE, I don’t think I’ve ever had SELinux get in my way for anything.