Intel In Bed with NSA? • Hacker News Board

Re: Intel In Bed with NSA?

#71

Post by EthanHeilman » Mon, Jul 15, 2013, 1:35 AM UTC

twoodfin wrote: post #65

EthanHeilman wrote: post #60

Earlier quoted context omitted.

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.

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

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

Re: Intel In Bed with NSA?

#72

Post by nodata » Mon, Jul 15, 2013, 7:22 AM UTC

nknighthb wrote: post #66

nodata wrote: post #64

Earlier quoted context omitted.

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

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 fundamen…

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

Re: Intel In Bed with NSA?

#73

Post by nknighthb » Tue, Jul 16, 2013, 5:17 PM UTC

nodata wrote: post #72

nknighthb wrote: post #66

Earlier quoted context omitted.

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 fundamen…

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

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