4 ms·

SELinux works well nowadays. You'd know that if you hadn't disabled it.

• nknighthb 13y ago
  If I hadn't disabled it... which of the dozens of times it's gotten in my way on a new image? Most recently last week, by the way. I disable it because it prevents correct code from running in an already-secure environment. I don't bother beforehand, because I inevitably forget. And then waste ten minutes before I realize I need to turn off the magic "break everything" switch. In the last seven days, has the fundamental incompatibility between SELinux's design and traditional Unix permissions and tools been suddenly corrected? Has tooling been created to allow us mere mortal sysadmins and engineers to understand and manipulate the byzantine SELinux configuration? I didn't think so.
  • nodata 13y ago
    > which of the dozens of times it's gotten in my way on a new image What was one recent example? > an already-secure environment Not possible. > has the fundamental incompatibility between SELinux's design and traditional Unix permissions and tools been suddenly corrected You mean labels? No, that's pretty fundamental to SELinux. > Has tooling been created to allow us mere mortal sysadmins and engineers to understand and manipulate the byzantine SELinux configuration? Try setroubleshoot.
    • nknighthb 13y ago
      > What was one recent example? System Apache unable to listen on non-standard port. > Not possible. Tell me of a vulnerability on a fully-updated RHEL 6 image running only SSH and a basic Apache configuration serving static files which would be prevented by the stock SELinux configuration. > You mean labels? No, that's pretty fundamental to SELinux. Exactly. So my explicit decisions about file permissions must be duplicated. No thanks. > Try setroubleshoot. So, no.