> It is really, really hard for me to see this as anything other than utter paranoia.
It is really really hard for me to imagine Intel not beeing 100% cooperative with the NSA.
It is really really hard for me to imagine Intel not beeing 100% cooperative with the NSA.
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.
You mean that damned monstrosity I always disable? You're claiming it's not a plot to make Linux utterly unusable?
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.
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.
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.
The NSA choose the key size of DES since they were running the process (making DES 256 times weaker than a 64 bit key).