Surely a machine owner can patch Fedora to permit Kexec w/ Secure Boot
Just like DVD's css and Blu-Ray DRM, once again a corporate attempt to control what people do with what they have already bought and paid for has been defeated!
Should be easy enough to reconfigure Fedora (or anything else) to permit kexec with secure boot, say for a machine with a locked/buggy UEFI that does not permit turning Secure Boot off. For this a signed kernel NOT booting into any kind of Secure Mode would be booted with secure boot still activated. I think this is Ubuntu's default approach, as it makes the use of proprietary or other third party drivers much easier, as they do not have to be signed. Ubuntu Server should probably offer an option to change that, however. After all, blocking unsigned modules (or ALL modules) is an established technique to harden any system that will be run only with known hardware, such as a server, and is ineffective if a reboot to an arbitrary kernel is possible. Ideal approach would be a boot-time only option for secure mode or not, on the same signed kernel bootable from UEFI with Secure Boot enabled.
I could see cases, such as UEFI only accessable from inside Windows, where a kexec-style exploit is needed to essentially root your laptop. Still chicken-and-egg if starting from Linux on machines that offer no option to stop Windows 8 from booting and have a soldered-down disk, however. The other problem is machines like the MS Surface, with no option to run anything but Windoze. For these, a port of kexec to the Windows kernel would allow rebooting to Linux, either for a session or to load code to root the firmware to install other keys and/or disable Secure Boot. That will be the final crack of Secure Boot as a form of DRM. It took 6 months for someone to jailbreak the first iPhone, and they got a blizzard of bluffing threats from Crapple as I remember. Now rooted phones are everywhere, and Hollywood is crying.
I can really only see one reason to keep Secure Boot, given than kexec can reboot into Windows 8 or later. This would be for an attempt to obstruct the insertion of software keyloggers into /boot on encrypted machines. In the wild, the MSS(China secret police) is known to prefer hardware keyloggers, even on laptops. Suspect the same of the FBI, so this would be no guarantee even if it was perfect. The "evil maid" software keylogger is simple in theory but in practice in the field easy to run into surprises while trying to implement against unknown machines where you don't even know in advance what OS you will be facing, this the popularity or hardware keyloggers.
Just don't count on that TPM not to have additional, hidden keys for the NSA and maybe the FBI the way MS Windows itself and ATA security set password commands do. If it does, they
could sign their "evil maid" initramfs with that key instead of yours. Thus, we need an open-hardware TPM next, the kind you can drop into the motherboard socket and epoxy down. Only then will there be any "secure" in Secure Boot when the NSA (or possibly the MSS) is the adversary.
Until then, we gain much and lose almost nothing from exploits against Secure Boot. Its not secure, as the hardware itself cannot be trusted.
Originally posted by smitty3268
View Post
Just like DVD's css and Blu-Ray DRM, once again a corporate attempt to control what people do with what they have already bought and paid for has been defeated!
Should be easy enough to reconfigure Fedora (or anything else) to permit kexec with secure boot, say for a machine with a locked/buggy UEFI that does not permit turning Secure Boot off. For this a signed kernel NOT booting into any kind of Secure Mode would be booted with secure boot still activated. I think this is Ubuntu's default approach, as it makes the use of proprietary or other third party drivers much easier, as they do not have to be signed. Ubuntu Server should probably offer an option to change that, however. After all, blocking unsigned modules (or ALL modules) is an established technique to harden any system that will be run only with known hardware, such as a server, and is ineffective if a reboot to an arbitrary kernel is possible. Ideal approach would be a boot-time only option for secure mode or not, on the same signed kernel bootable from UEFI with Secure Boot enabled.
I could see cases, such as UEFI only accessable from inside Windows, where a kexec-style exploit is needed to essentially root your laptop. Still chicken-and-egg if starting from Linux on machines that offer no option to stop Windows 8 from booting and have a soldered-down disk, however. The other problem is machines like the MS Surface, with no option to run anything but Windoze. For these, a port of kexec to the Windows kernel would allow rebooting to Linux, either for a session or to load code to root the firmware to install other keys and/or disable Secure Boot. That will be the final crack of Secure Boot as a form of DRM. It took 6 months for someone to jailbreak the first iPhone, and they got a blizzard of bluffing threats from Crapple as I remember. Now rooted phones are everywhere, and Hollywood is crying.
I can really only see one reason to keep Secure Boot, given than kexec can reboot into Windows 8 or later. This would be for an attempt to obstruct the insertion of software keyloggers into /boot on encrypted machines. In the wild, the MSS(China secret police) is known to prefer hardware keyloggers, even on laptops. Suspect the same of the FBI, so this would be no guarantee even if it was perfect. The "evil maid" software keylogger is simple in theory but in practice in the field easy to run into surprises while trying to implement against unknown machines where you don't even know in advance what OS you will be facing, this the popularity or hardware keyloggers.
Just don't count on that TPM not to have additional, hidden keys for the NSA and maybe the FBI the way MS Windows itself and ATA security set password commands do. If it does, they
could sign their "evil maid" initramfs with that key instead of yours. Thus, we need an open-hardware TPM next, the kind you can drop into the motherboard socket and epoxy down. Only then will there be any "secure" in Secure Boot when the NSA (or possibly the MSS) is the adversary.
Until then, we gain much and lose almost nothing from exploits against Secure Boot. Its not secure, as the hardware itself cannot be trusted.
Comment