Announcement

Collapse
No announcement yet.

The UEFI SecureBoot Saga For Linux Continues

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

  • #16
    Barring firmware backdoors

    Barring firmware backdoors
    I think that's the real purpose of secure boot and UEFI. Not that there isn't a legitimate case for secure booting but if it prvents you from examining ALL the source code and the firmware then you don't really know who has ultimate control of your pc and data.

    Comment


    • #17
      Originally posted by Qaridarium View Post
      will it be possible to just flash a coreboot with flashrom over the BAD and EVIL UEFI ?
      Being able to flash would require a permission that would probably not be granted with Secure Boot enabled. The short answer is, no, you would not be able to overwrite the BIOS with something else unless you already disabled Secure Boot, which would then defeat most of the purpose of flashing the BIOS in the first place. I think you wanted to flash CoreBoot over top of UEFI while Secure Boot is ENABLED and I think this will either be 100.0% impossible, or will require "hacking" (hardware hacking or exploiting a security vulnerability).

      Comment


      • #18
        Originally posted by agd5f View Post
        secureboot is coming whether you like it or not. You may be able to disable secureboot in the bios, but every bios vendor will implement it differently and some may forget to implement it at all. How do you tell a new Linux user that they have to hit F11 or maybe Delete or maybe F2 during the first few seconds of boot and then wade through a bunch of bios menus to disable a feature called _secure_ boot (let that sink in) just so they can try out this new Linux thing. Kind of a high bar. Realistically you need to support secureboot if you want your OS to be accessible to a wide audience.
        I don't think it's just a BIOS thing. I think it's also a TPM chip built into your pc that's does the checking for keys and allowing which code can boot or not.

        Comment


        • #19
          Originally posted by Qaridarium View Post
          in your world professionals only use UEFI ? i think REAL Professionals use coreboot in the bios flash rom and a hardware jumper to set the boot rom to read only

          LOL !!! tell me how do a hacker BEAT this security solution ?
          That sounds pretty secure indeed, but requires toggling a switch on the motherboard each time you want to change any files in the operating system. Also, this method does not provide any way to verify that all of the binaries present on the system are genuine: if they were somehow modified through an exploit of some kind, you wouldn't be able to know.

          It's like if you send an HTTP request to a remote website without SSL enabled, and a response comes back, you don't know if someone in the middle has messed with the data somehow. You can't verify that it is coming from the endpoint that you sent your request to. But if you send an HTTPS request with SSL or TLS enabled, you are practically guaranteed (barring any vulnerabilities in SSL) that no hosts sitting between you and your endpoint were able to modify the data. If they were, it would immediately fail your message digest check, and your browser would give you a big error message.

          This is what secure boot does, but instead of network data, it verifies executable code on disk.

          My personal commitment to fight secure boot's unnecessary restrictions on regular users is this: I will never purchase a consumer device (PC, laptop, tablet, smartphone, etc) that has Secure Boot enabled, and cannot be disabled. Those devices can sit on the shelves in the stores, and I will buy devices that let me customize the operating system how I want to.

          However, if someone expresses interest in using secure boot in an enterprise context (a server, I mean), I will probably let them know that it can be a good thing, if you know what you're doing. But it does add a lot of unnecessary headache to the configuration/installation of the operating system and software, so we'd have to perform a feasibility investigation to make sure that there are no roadblocks.
          Last edited by allquixotic; 06-01-2012, 12:52 AM.

          Comment


          • #20
            Originally posted by allquixotic View Post
            Being able to flash would require a permission that would probably not be granted with Secure Boot enabled. The short answer is, no, you would not be able to overwrite the BIOS with something else unless you already disabled Secure Boot, which would then defeat most of the purpose of flashing the BIOS in the first place. I think you wanted to flash CoreBoot over top of UEFI while Secure Boot is ENABLED and I think this will either be 100.0% impossible, or will require "hacking" (hardware hacking or exploiting a security vulnerability).
            i mean something like this: flashing coreboot on a bios chip and then replace the bios chip

            maybe this is the first act for linux users in the future.

            and explain to me why is a hardware jumper to set the bios flash to read only not a better solution than UEFI ?

            Comment


            • #21
              Originally posted by allquixotic View Post
              That sounds pretty secure indeed, but requires toggling a switch on the motherboard each time you want to change any files in the operating system. Also, this method does not provide any way to verify that all of the binaries present on the system are genuine: if they were somehow modified through an exploit of some kind, you wouldn't be able to know.

              It's like if you send an HTTP request to a remote website without SSL enabled, and a response comes back, you don't know if someone in the middle has messed with the data somehow. You can't verify that it is coming from the endpoint that you sent your request to. But if you send an HTTPS request with SSL or TLS enabled, you are practically guaranteed (barring any vulnerabilities in SSL) that no hosts sitting between you and your endpoint were able to modify the data. If they were, it would immediately fail your message digest check, and your browser would give you a big error message.

              This is what secure boot does, but instead of network data, it verifies executable code on disk.
              "But if you send an HTTPS request with SSL or TLS enabled, you are practically guaranteed (barring any vulnerabilities in SSL) that no hosts sitting between you and your endpoint were able to modify the data. If they were, it would immediately fail your message digest check, and your browser would give you a big error message."

              this is just wrong because SSE is based on "Trust" and the "Trust" part is the vulnerability because in the past the "Trust" centers allow untrusted people to violate there "Trust" to hijack your "security" (DigiNotar CA certificate abuse) source: http://support.mozilla.org/de/questions/872516

              only PGP is save from this kind of attack. '


              "This is what secure boot does, but instead of network data, it verifies executable code on disk"

              now you get the same problem on the hardware side the Criminal "Microsoft" and the Criminal "Government" get the power of "certificate abuse)

              now a example you store your 1 million dollar of Bitcoins on your "server" and you trust "LOL-UEFI-LOL" then the "Good" Government make Bitcoins against the law but only to rape the bitcoins and sell them to earn money for buying weapons to start a "war"

              now the government with the name USA go to there company with the name MIcrosoft and do a certificate abuse and now what do you get?

              UEFI is only power in the hand of microsoft and govnernment insteaf of power in your hand!

              because UEFI is based on "Trust" but first rule in security is: "do not trust"

              back to my unbeatable (unbeatable for the real evils like government)solution:

              "That sounds pretty secure indeed, but requires toggling a switch on the motherboard each time you want to change any files in the operating system."

              this is wrong because this is only the security of the lowest level you build a virtualization with hardware emulation because of this the "Virus" always manipulate the emulated hardware and never the REAL hardware

              " Also, this method does not provide any way to verify that all of the binaries present on the system are genuine:"

              this is also wrong because the virtualization emulation do have a 1on1 copy of the original files so they can compare it all the time no way to escape this one.
              Last edited by Qaridarium; 06-01-2012, 01:08 AM.

              Comment


              • #22
                in my point of view its impossible to support linux on UEFI hardware because of the GPL3 and also GPL2 interpretation

                "
                Now, obviously, we could provide signed versions of Linux. This poses several problems. Firstly, we'd need a non-GPL bootloader. Grub 2 is released under the GPLv3, which explicitly requires that we provide the signing keys. Grub is under GPLv2 which lacks the explicit requirement for keys, but it could be argued that the requirement for the scripts used to control compilation includes that. It's a grey area, and exploiting it would be a pretty good show of bad faith. Secondly, in the near future the design of the kernel will mean that the kernel itself is part of the bootloader. This means that kernels will also have to be signed. Making it impossible for users or developers to build their own kernels is not practical. Finally, if we self-sign, it's still necessary to get our keys included by ever OEM."

                http://mjg59.dreamwidth.org/5552.html

                there is a possibility that the kernel and GPLv2 is also incompatible with the UEFI standards.

                i hope so! then lawyers can stop this and then Microsoft will get some anti-trust problems to.

                Comment


                • #23
                  security boot and UEFI is just: "The Coming War on General Purpose Computation"

                  http://boingboing.net/2011/12/27/the...eral-purp.html

                  Comment


                  • #24
                    Easy enough: avoid any hardware with a Windows 8 sticker?
                    This is what I am going to do...

                    Little example, me buying a netbook:
                    1. tell the vendor to rip out the hard drive and put a SSD in
                    2. do not bother to install Windows on it and keep the licence
                    3. after some research, the third vendor was OK with that

                    Comment


                    • #25
                      @Q

                      Kanotix is definitely not dead, maybe look at our homepage, we just release a Hellfire (squeeze) update and a Dragonfire (wheezy) preview.

                      But if EVERYBODY can get a signed bootloader then this system is absolutely pointless. For x86 you just have to find a setup option to disable secure boot - usually secure boot can only work in uefi mode anyway. So when you would force a boot via csm (and bios emulation) how should secure boot be active if thats done via quick boot selection?

                      If you see secure boot as something positive to your own security that means that could be sure that nobody managed to put in a spy module to save your encryption keys if you encrypt your data like it is possible when you hijack the mbr for this and then execute maybe truecrpt later but store the key.

                      I don't understand why ms would give away a signed 3rd party efi loader, you can be 100% sure that it will be used for exploits. If you dont need security features you can disable em on your own. It would be interesting to know if there is a uefi spec to update the included public keys. Basically it should not be that hard to do when you have got access to the uefi, you can extract, change (there are several tools to modifiy uefi, just for another purpose currently) and flash your own keys.

                      Even if the key area would be write protected after first write you could still replace the eeprom chip, which is a piece of cake on a desktop system, well could be tricky on a laptop. When YOU are able to control it, then you can gain a little bit more security, if you cant it would be just like without.

                      Comment


                      • #26
                        Originally posted by linux5850 View Post
                        I don't think it's just a BIOS thing. I think it's also a TPM chip built into your pc that's does the checking for keys and allowing which code can boot or not.
                        In the comments section, someone asked about TPM, and the response was that SecureBoot is designed not to require one.

                        Comment


                        • #27
                          Originally posted by Kano View Post
                          @Q

                          Kanotix is definitely not dead, maybe look at our homepage, we just release a Hellfire (squeeze) update and a Dragonfire (wheezy) preview.

                          But if EVERYBODY can get a signed bootloader then this system is absolutely pointless. For x86 you just have to find a setup option to disable secure boot - usually secure boot can only work in uefi mode anyway. So when you would force a boot via csm (and bios emulation) how should secure boot be active if thats done via quick boot selection?

                          If you see secure boot as something positive to your own security that means that could be sure that nobody managed to put in a spy module to save your encryption keys if you encrypt your data like it is possible when you hijack the mbr for this and then execute maybe truecrpt later but store the key.

                          I don't understand why ms would give away a signed 3rd party efi loader, you can be 100% sure that it will be used for exploits. If you dont need security features you can disable em on your own. It would be interesting to know if there is a uefi spec to update the included public keys. Basically it should not be that hard to do when you have got access to the uefi, you can extract, change (there are several tools to modifiy uefi, just for another purpose currently) and flash your own keys.

                          Even if the key area would be write protected after first write you could still replace the eeprom chip, which is a piece of cake on a desktop system, well could be tricky on a laptop. When YOU are able to control it, then you can gain a little bit more security, if you cant it would be just like without.
                          i know your releases ok bad style it was more a question will you support secure-boot in the future and will you pay 100 dollar to microsoft ?

                          Comment


                          • #28
                            No i wont because if somebody does not find the option to disable secure boot he is most likely not able to use linux as well...

                            Comment


                            • #29
                              Originally posted by Kano View Post
                              No i wont because if somebody does not find the option to disable secure boot he is most likely not able to use linux as well...
                              lol ;-) maybe i will use kanotix in the future only to prove that I'm able to find the bios option

                              Comment


                              • #30
                                I think there are better reasons to use Kanotix. But you should not mix up standard uefi booting with secure boot. uefi boot is really cool when done correctly - especially with a kernel with efi stub. It is a bit weird that you can use "rdev" now for that purpose which was already dropped from utils-linux because nobody used it...

                                Comment

                                Working...
                                X