[kllrnohj]

You know who else cooperates with the NSA? The Linux community. You know, that whole "SELinux" thing? Yeah, that's an NSA project.

Turns out cooperating with the NSA doesn't automatically mean spying on the public, it could instead be hardening crypto security. Which is the NSA's other job, it turns out.

[EthanHeilman]

Yes and no better example than DES in which the NSA hardened DES against differential cryptanalysis and then reduced the key size from 128 bits to 54 bits so they could break it. Given the prior actions of the NSA is doesn't seem unbelievable that they would both harden and backdoor linux.

[twoodfin]

Who was arguing for 128-bit DES? Wikipedia says IBM wanted 64.

[EthanHeilman]

The original version of DES was called Lucifer and used a 128 bit key. http://en.wikipedia.org/wiki/Lucifer_(cipher)

The NSA choose the key size of DES since they were running the process (making DES 256 times weaker than a 64 bit key).

[autodidakto]

I assume he means "cooperating with NSA in nefarious ways if the NSA wanted".

[nknighthb]

> You know, that whole "SELinux" thing?

You mean that damned monstrosity I always disable? You're claiming it's not a plot to make Linux utterly unusable?

[nodata]

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

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