Page 3 of 8 FirstFirst 12345 ... LastLast
Results 21 to 30 of 71

Thread: The UEFI SecureBoot Saga For Linux Continues

  1. #21
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote 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 at 01:08 AM.

  2. #22
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    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.

  3. #23
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

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

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


  4. #24
    Join Date
    Nov 2009
    Posts
    379

    Default

    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

  5. #25
    Join Date
    Aug 2007
    Posts
    6,607

    Default

    @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.

  6. #26
    Join Date
    Oct 2011
    Location
    Seattle, WA, USA
    Posts
    82

    Default

    Quote 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.

  7. #27
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote 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 ?

  8. #28
    Join Date
    Aug 2007
    Posts
    6,607

    Default

    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...

  9. #29
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote 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

  10. #30
    Join Date
    Aug 2007
    Posts
    6,607

    Default

    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...

Posting Permissions

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