[nknighthb]

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]

> 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]

> 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.