SELinux

Just for the record: SELinux can lick my sweaty balls.

I mean seriously. This is the biggest, most uselessly time-wasting piece of shit since the last time they rewrote the firewall code from scratch.

Tags: ,

28 Responses:

  1. dachte says:

    I try it for about a week every time I upgrade Fedora, and find it's still crap. Then I use system-config-securitylevel to turn it off.

    • kniedzw says:

      I'm with you on that. I played around with it for a while in ES3 so I could know it well enough to get an RHCE and then promptly forgot it all.

  2. 7ghent says:

    Seriously.

  3. wisedonkey says:

    You just need to find the right patch and update to cvs head to get it to work. Yeah, I'm sure that's got to be it.

  4. What version of what distribution are you running into SELinux problems with?

    In the Fedora space there's been work done to develop tools such as SETroubleshoot which make it a bit easier to use, and at least identify the parts that need to be turned off if you want to use a small hammer, instead of a big one.

    There are more improvements to the tools on the way, as well.

    • jwz says:

      I'm running version STFUFOAD.

    • bitwise says:

      Here you go, we've broken a bunch of things that have worked without complaint for ten years. Sorry bout that. Maybe in the next version you'll get an error message that makes sense.

      In the meantime, here's a fancy tool to help you debug the problem!

  5. brianenigma says:

    Agreed!

    Computer security is a balance between security and usability. SELinux's scale is a bit too heavily weighted to one side.

    • jered says:

      Mmmmm...reminds me of Tomcat/Catalina, and J2EE application servers in general.

      "Let's use something in a way it wasn't designed for... by crippling it horribly!"

  6. simbab says:

    I assume you were using Fedora...they're the only ones I know of who use it out of the box. Debian is getting there but I don't think it'll ship in etch.

    My experience has been it's getting better. I tried FC6 x86_64 a few weeks ago and had no major problems in typical desktop usage. Compare that with, say FC3 which had a number of serious out-of-the-box issues directly solved by turning off SELinux.

    Personally, I have little use for it. I can understand where a more complex security model might have it's uses, but there aren't any for me.

    Better watch what you say about SELinux...the NSA is ever-powerful these days you know...

    • benediktus says:

      Better watch what you say about SELinux...the NSA is ever-powerful these days you know...

      ... you mean.. they will come and lick his balls?

      fc6 selinux sucked, so i set it to stfu. ...and there was much rejoicing.

    • zaitcev says:

      No fair disturbing the echo-chamber!

  7. Yeah, as much as the idea of making Linux more secure is great and all, in practice, it just pisses you off, and then you have to shut it off and hope nothing else breaks in the process.

  8. sweh says:

    SELinux is overkill for 99.999% (number pulled out of arse) of Linux users. Much like SEOS (a similar third party commercial product) on Solaris is overkill for most installs.

    It's hard to configure properly, will just get in the way and stops the system from working correctly. Distributions that provide it by default are stupid. Distributions that turn it on by default are even stupider. Yes, RHEL (and thus CentOS and probably others) I'm looking at you.

    Fortunately I learnt the lesson and now look carefully at the install screens and chose the "Disable" option at install time.

    Guh.

    • Yeh, and my experience with other operating systems that implement ACLs and other complex in-kernel security policies is that they just lead to security holes. UNIX's normal security model is easy to audit; adding a zillion new kinds of privilege and context-dependent permissions just means more things to go wrong.

      Also, you kids, get off my lawn!

    • darkengobot says:

      Unless something has changed recently, CentOS doesn't turn SELinux on by default. It asks you if you want it on, off, or in "warn". I think it defaults to "warn". Actually it's been a while since I installed CentOS... maybe it does default to on.

      This post was useless. Now I have to lick somebody's sweaty balls. What wine goes with nutjuice?

  9. xenogram says:

    [Suggestion from irritating technocrat that you attempt complicated timeconsuming solution, inviting sarcastic response]

  10. sneakums says:

    Your balls are only sweaty because your security is not enhanced and you can't take the fear.

  11. transgress says:

    well why dont you sit down and learn to use it properly, although chances are you don't need to go that hardcore with ACLs

    • rapier1 says:

      Security is useless if its too invasive, too slow, or too difficult to use. SELinux seems to ring cherries on at least 2 if not 3 out of 3. Security people keep seeming to forget that users are clever (even dumb ones end up being clever somehow) and will circumvent security systems if they get in the way.

  12. wire_on_fire says:

    that you run OpenBSD on machines you really don't wana get r00ted, do I have to lick your sweaty balls?

  13. You're a smart guy, JWZ, and I would really like to hear why you think SELinux sucks. Yes, I know that lots of people on here have already agreed with you and filled-out your argument, but I'm curious to hear what you have to say. (I ask because I'm considering implementing it for a particular server as an additional security measure.) It's a let-down to just have someone smart say "blah sucks" and then not back it up with anything.

    • Because no matter what flavour of linux, unless you're planning to run a multiuser system (I.E. you give random people restrictive shells), SELinux and pals are a complete waste of time when any vaugly competant sys admin can configure apache/ssh/etc in ways that make them relatively hard to remote root, then all you need to do is keep an eye on the security updates, for the 2-3 services which are publically accessible on the box.

      The alternative is a box which uses a bunch of custom tools to configure, which change every time some kiddie somewhere thinks it's a great idea to rewrite it to make it faster. And then once you've learnt the tools, chances are you'll screw up and lock yourself and everyone else out of the box. This assumes the software has no bugs and you don't manage to hit one of the configurations which they haven't gotten around to testing yet, and your kernel goes and eats it's own arse.

      You don't need to be particularly smart to realise this.

  14. moof says:

    I had one coworker who deserved multiple stabbings to the face; instead of debugging code he wrote, he just wrote entirely new code instead beause "it was faster!"

    Every time I hear about the PAM/security model/batt3l hard3n3d/mumble of the week, I get flashbacks to him.