Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23

Thread: ELF Executable Signing/Verification Comes For Linux

  1. #11
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    Quote Originally Posted by Mickabouille View Post
    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.

  2. #12
    Join Date
    Sep 2012
    Posts
    289

    Default

    Quote Originally Posted by Mickabouille View Post
    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...

  3. #13
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    Quote Originally Posted by wargames View Post
    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?

  4. #14
    Join Date
    Mar 2009
    Posts
    47

    Default

    Quote Originally Posted by crazycheese View Post
    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.

  5. #15
    Join Date
    Dec 2011
    Posts
    2,049

    Default

    Quote Originally Posted by Rexilion View Post
    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.

  6. #16
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    Quote Originally Posted by Mickabouille View Post
    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 View Post
    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 View Post
    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.
    Last edited by crazycheese; 01-16-2013 at 09:36 AM.

  7. #17
    Join Date
    Dec 2012
    Posts
    459

    Default

    Quote Originally Posted by uid313 View Post
    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 View Post
    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.
    Last edited by Rexilion; 01-16-2013 at 09:34 AM.

  8. #18
    Join Date
    Jul 2008
    Location
    Germany
    Posts
    677

    Default

    Quote Originally Posted by Rexilion View Post
    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.

  9. #19
    Join Date
    Sep 2010
    Posts
    467

    Default

    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.

  10. #20
    Join Date
    Dec 2012
    Posts
    459

    Default

    Quote Originally Posted by Nille View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •