The UEFI SecureBoot Saga For Linux Continues

[Qaridarium]

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.

[Qaridarium]

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.

[Qaridarium]

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

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

[disi]

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

[Kano]

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

[steveriley]

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.

[Qaridarium]

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

[Kano]

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

[Qaridarium]

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

[Kano]

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