Announcement

Collapse
No announcement yet.

ELF Executable Signing/Verification Comes For Linux

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic ELF Executable Signing/Verification Comes For Linux

    ELF Executable Signing/Verification Comes For Linux

    Phoronix: ELF Executable Signing/Verification Comes For Linux

    Vivek Goyal of Red Hat has published the initial Linux patches for implementing ELF executable signing and verification. This support is similar to Linux kernel module signature verification and is necessitated with the arrival of SecureBoot...

    http://www.phoronix.com/vr.php?view=MTI3NTY

  • Jarrod558
    replied
    So exist an key management or something like that?

    Leave a comment:


  • RCL_
    replied
    That sounds like it's against the GPL, at least as long as user-space binaries are concerned. You can modify and recompile, but you cannot run. Someone who provided you with a signed user-space binary should have provided you with a key to sign it as well, i.e. ability to modify it and redistribute modifications.

    I think it should not matter whether you can turn that feature in kernel off or not, because kernel is licensed separately and is not considered a part of the program. As far as I understand GPL, keys should be included in source code, according to this definition:

    "The "Corresponding Source" for a work in object code form means all
    the source code needed to generate, install, and (for an executable
    work) run the object code and to modify the work, including scripts to
    control those activities."

    Leave a comment:


  • Nille
    replied
    Originally posted by Rexilion View Post
    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?
    RedHat, Novel oder Canonical can easy setup an Infrastructure for there Distributions.

    Originally posted by Rexilion View Post
    As for configuration, you can assert that for every defense mechanism.
    But its much much easer to Sign an program as to write an complete and secure selinux policy for each (!) program.

    Leave a comment:


  • Rexilion
    replied
    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.

    Leave a comment:


  • plonoma
    replied
    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.

    Leave a comment:


  • Nille
    replied
    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.

    Leave a comment:


  • Rexilion
    replied
    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.

    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, 10:34 AM.

    Leave a comment:


  • crazycheese
    replied
    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.

    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.

    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, 10:36 AM.

    Leave a comment:


  • uid313
    replied
    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.

    Leave a comment:

Working...
X