ELF Executable Signing/Verification Comes For Linux

Quote:

---

Originally Posted by Mickabouille

Yet another attempt to lock down our own computers.

---

No. Its like car lock. Its good. Its will be bad ONLY if car vendor has control, not car owner.

Either it protects you or protects computer from you depends on its implementation and as state of things - you have full control over it.

So don't tell me you don't use password on your phoronix account - because its an attempt to lock you down from phoronix.

Quote:

---

Originally Posted by Mickabouille

Yet another attempt to lock down our own computers.

---

Yeah, the CIA and the NSA are trying hard to lock down our computers and install backdoors everywhere. I wonder how many of them work for RH. Today everyone thinks this is a good idea, in a couple of years it will be mandatory and then using open source will be considered illegal with the excuse of protecting us from the terrorists...

Quote:

---

Originally Posted by wargames

Yeah, the CIA and the NSA are trying hard to lock down our computers and install backdoors everywhere. I wonder how many of them work for RH. Today everyone thinks this is a good idea, in a couple of years it will be mandatory and then using open source will be considered illegal with the excuse of protecting us from the terrorists...

---

The answer will be a question: can you turn it off?

Quote:

---

Originally Posted by crazycheese

No. Its like car lock. Its good. Its will be bad ONLY if car vendor has control, not car owner.

---

No, It's more like : You can't open your car engine if you don't have a special screwdriver that only the car vendor mechanics have.

My point : stop analogies, they're out of context.

Quote:

---

Originally Posted by Rexilion

It's there, it's called debsums. Don't know if you need to install it seperately.

But these methods are not for data integrity. MD5 has collisions and so two different executables can be created with the same checksum.

This technology is about a checksum inside the programs 'physical' file which is probably signed/hashed/encrypted by some certificate (or key or whatever). Hence, it's possible to use the public (root) certificates to check this.

I find these integrity mechanisms flawed, as a vulnerable signed executable is still vulnerable. It gives a false sense of security. One might argue that you are reducing the attack surface but I would say that is not the case. Say, you exploit Java, which is relatively easy, and then root exploit into Linux. Simply place a python script and make it start at boot with a new entry into a boot script (both of which are not covered by this mechanism) and you are good to go.

And did I mention the fallacy's of Turktrust and Diginotar? Perfectly signed binaries ... now with trojans!

---

Thanks, I didn't know about debsums.
I guess they should change from MD5 to SHA-1, SHA-2, or SHA-3 then.

Perfectly signed binaries on malware are still relatively uncommon. So the protection would arguably be better than nothing at all.

Quote:

---

Originally Posted by Mickabouille

No, It's more like : You can't open your car engine if you don't have a special screwdriver that only the car vendor mechanics have.

---

Car lock is better projection, because it denies ability to use car if the key is not matching.
Hence my analogy upholds.

Your analogy is better suited to ELF obfuscation. You can drive the car, but you can't figure out how it drives.
Its completely different area, mostly a con than a pro. But imagine situation where you need your server binaries to work, yet be useless for cracker to disassemble/analyse if he cracks your machine. For example, banking field.
Hence the true protection is the LICENSE, which legally prohibits misusing the double-edged tools. This is why GPL is simply a brilliant thing, and BSD is unsuitable in this context.

Quote:

---

Originally Posted by Mickabouille

My point : stop analogies, they're out of context.

---

Analogy is simulation and approximation. Simulation is a valid scientific method, granted it always can have deviations due to incomplete data.
The complete data test would be field testing, so lets wait for actual implementation to see outcome.

Quote:

---

Originally Posted by uid313

Thanks, I didn't know about debsums.

---

Debsums (and in case of source-based, CRCing the source) are unrelated.
The idea is to execute only the code which has not deviated.
Package CRC idea is to deliver the package which has not deviated. Its comparable to archive CRC.
Overall it nicely adds up, you get checksums in git, checksums on package, authentication on download and authentication when binary is executed.

Quote:

---

Originally Posted by uid313

Thanks, I didn't know about debsums.
I guess they should change from MD5 to SHA-1, SHA-2, or SHA-3 then.

---

The use of an outdated hash like MD5 (which performs fast) highlights debsums true purpose. The chance, that a file is modified due to a crash of any kind and yielding the same MD5 hash is near (as in 1/10^99) 0. The benefits of using any other algorithm will not yield any benefits at all.

Quote:

---

Originally Posted by uid313

Perfectly signed binaries on malware are still relatively uncommon. So the protection would arguably be better than nothing at all.

---

True, imagine the fun that would unravel if hackers had a private key for years without anyone noticing. I point at Diginotar and Turktrust again. However, this is the same argument as using: Selinux makes it harder to compromise a system. How many additional layers of security will people need/want? Instead of focusing on code and fixing bugs real quick like Oracle not patching Java, these frameworks are invented. I smell a conspiracy to be honest...

Besides, why not tacke issue's at the origin but rely on another layer? A quickly fixed security bug beats a security layer in nearly every concievable argument for which this exact same layer was introduced in the first place.

Quote:

---

Originally Posted by Rexilion

Selinux makes it harder to compromise a system.

---

Only if its correct configured. If you can setup your system that it execute only signed Applications ( The from you distributions and an List from Allowed Vendors ) its an very easy and a high wall for malware.

Bwahahahahaaaaaaaa.

Here we go again with the magic of verification and signing which makes everything okay because nothing can't ever be built without modelling real-world analogies in computer stuff.

Quote:

---

Originally Posted by Nille

Only if its correct configured. If you can setup your system that it execute only signed Applications ( The from you distributions and an List from Allowed Vendors ) its an very easy and a high wall for malware.

---

You also have to look at the other side, i.e. the distribution. It has to setup infrastructure to verify and sign every binary that passes. And who says that distributions have proper security mechanisms preventing the keys from being stolen/abused? Even kernel.org got hacked. Why not some random server from Ubuntu?

As for configuration, you can assert that for every defense mechanism.