Announcement

Collapse
No announcement yet.

ELF Executable Signing/Verification Comes For Linux

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

  • 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

  • #2
    Jailbreak your Linux OS?

    Comment


    • #3
      Other OS already had this

      Other operating systems already had this feature for many years now.

      It would be if the distribution signed all their compiled binaries.
      Then you can verify the integrity of the system by searching for binaries that are not signed by the distribution.

      A tool that lists all non-signed binaries, and all non-distribution signed binaries.

      Comment


      • #4
        Originally posted by uid313 View Post
        It would be if the distribution signed all their compiled binaries.
        Then you can verify the integrity of the system by searching for binaries that are not signed by the distribution.

        A tool that lists all non-signed binaries, and all non-distribution signed binaries.
        all RPM based distributions have got that ability out-of-the-box. or maybe not exactly that- rpm -V doesn't check is a binary signed (or not), but it checks the checksum of package- if binary was modified (stripped etc), than it will notify you.
        Making the list of all executables, than comparing it to the listed packages will let you know if they are executables that were not installed via rpm... you can always of course check their signatures etc.
        So, in short- thing like that is already possible.

        But ad rem- i'd like to be able to, let say, automatically run un-signed executables in SELinux's sandbox. Of course- I should be able to either disable it, or to add my own signature to the signature-database.

        Comment


        • #5
          Originally posted by uid313 View Post
          Then you can verify the integrity of the system by searching for binaries that are not signed by the distribution.
          But in order to have a system with verifiable integrity, you'll also need to disable the root user (he can bypass checks), third party kernel modules (you can't sign them with the distribution's key when you build them), scripts (they can't be signed) or their interpreters (python, java, php... bash...).

          I think that this feature is more useful for users to be sure of the author of binaries rather than as a lock-down measure.

          Comment


          • #6
            So exist an key management or something like that? "One Key to Rule them all" is not an great idea and i would like it that Software Vendors can sign there own Binary. Our administrators have only to allow that Vendor and we don't have to Sign all binary by ourself.

            Under Windows its easy to do that and we use this Feature with our own Workstations. You can only execute programs that are signed from Vendors that are in an white list.
            Last edited by Nille; 01-16-2013, 06:10 AM.

            Comment


            • #7
              Since the content is protected by license (GPL) and not technical obfuscation, this is a very welcomed feature.
              Even on regular systems it makes sense as it will provide protection against bitrot and damage, even before the binary is executed.

              Comment


              • #8
                Yet another attempt to lock down our own computers.

                Comment


                • #9
                  Originally posted by szymon_g View Post
                  all RPM based distributions have got that ability out-of-the-box. or maybe not exactly that- rpm -V doesn't check is a binary signed (or not), but it checks the checksum of package- if binary was modified (stripped etc), than it will notify you.
                  Making the list of all executables, than comparing it to the listed packages will let you know if they are executables that were not installed via rpm... you can always of course check their signatures etc.
                  So, in short- thing like that is already possible.

                  But ad rem- i'd like to be able to, let say, automatically run un-signed executables in SELinux's sandbox. Of course- I should be able to either disable it, or to add my own signature to the signature-database.
                  Sweet!
                  I wish these feature were available on .deb / apt-based distributions too.

                  Comment


                  • #10
                    Originally posted by uid313 View Post
                    Sweet!
                    I wish these feature were available on .deb / apt-based distributions too.
                    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!

                    Comment


                    • #11
                      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.

                      Comment


                      • #12
                        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...

                        Comment


                        • #13
                          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?

                          Comment


                          • #14
                            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.

                            Comment


                            • #15
                              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.

                              Comment

                              Working...
                              X