5 ms·

> Which is why what we really need is the ability to set properties on each network port and have those persist across reboots. SELinux can effectively do this

• worthless-trash 4y ago
  I think you're overstating the additional complexity, just a little.
  • Spivak 4y ago
    SELinux on CentOS 7+ is basically turnkey. If you’re turning it off you’re doing yourself a disservice.
    • worthless-trash 4y ago
      Can't agree more.
• thayne 4y ago
  > Admittedly this seems like using a crane and wrecking ball to hang a painting Precisely. SELinux is incredibly complicated. It would be nice to have something simpler.
  • Spivak 4y ago
    Anything you invent that can confine software from the outside will become SELinux. SELinux is actually really simple, you tag stuff and write rules about what tags can and can’t do to other tags. And writing your own policies, while strange and esoteric because it uses m4, is straightforward. SELinix is hard because you really have to know what’s going on with your software to actually write these policies. The complexity is in creating a maintainable system of tags and rules with software that does all kinds of crazy weird things. The complexity is irreducible. The only thing you can really do is create tools to handle common cases and that’s semanage.
    • vlovich123 4y ago
      And yet I recall managing launchd security policies to be a fraction of the complexity to manage and easier to verify you were doing the thing you intended. As compared with Android where I observed SELinux required far more man power to maintain / complexity / foot guns. Now maybe SELinux is indeed more powerful. I’m not well versed enough in that problem domain to do a comparison. In terms of successfully getting broad adoption across teams of various skill sets, I’d say the launchd approach is better holistically.
      • tux1968 4y ago
        I thought launchd was more akin to systemd than to selinux or apparmor. Some brief googling didn't show anything about security policies. Do you have a link where I could learn some more?
        • vlovich123 4y ago
          I don't know that there's anything external and it's possible I may have misremembered. Performance limits are managed in launchd (maximum memory etc). File access security is managed by setting a class on the file via ioctl which controls when the file is accessible (after first unlock, while screen is unlocked, etc). Maybe there isn't a secondary security layer? Can't recall now but I swear I thought the launchd plist described it all. I don't have a Mac anymore so I can't even look at the plist contents to double-check.
    • mindwok 4y ago
      I disagree that the complexity is irreducible. SELinux really complicates things by having compiled policies that have their own tool chain, and (although this is definitely debatable) using file system labelling versus just paths (like AppArmor for example). I know there are shortcomings for paths versus labels, but administrators are much more used to working with paths and simple config file, versus labels and compiled policies written in a DSL. In addition, the auditing system for understanding what SELinux is actually doing is complicated, so much so that there’s additional tools around it that allow you to pipe the logs into so you can get something resembling a human explanation for what’s going on. None of this is irreducible. SELinux does itself no favours by having a complicated tool chain with a terrible user experience. And I say this as someone who always leaves SELinux enabled…