Le lundi 2 juillet 2012 18:42:13, Steve McIntyre a écrit : > Hey folks, > > As you might have seen from recent discussions about the Fedora and > Ubuntu strategies for how to deal with EFI and Secure Boot, there are > potentially major issues in the area. In Debian we don't (yet) have a > plan, so it's high time that we had some discussion. I've set up a BoF > at DebConf for this: > > https://penta.debconf.org/penta/schedule/dc12/event/925.en.html > > That's Monday 9th July, 15:00 local time (21:00 UTC). Sorry for my naive questions but I want to be sure I understand the goal behind secure boot correctly. I'm not talking about Microsoft here but as stated by Bdale yesterday there is many people who see a value in secure boot to protect their system. Please correct any mistake I do in my reasonning and if I'm plain wrong just ignore my email or send me a notice on IRC or private email. Suggestions for the implementation are after the questions. What I'd really like to understand is why is protecting the boot so important for these people? Secure boot is designed to prevent booting code anywhere in the boot sequence which is infected by a malware. But if such an infection happens, it means a flaws in the system was used during the last run. It should normally not be possible to modify any of the code in the boot sequence without appropriate privilege. When the flaws was exploited, then the attacker had sufficient access to change e.g. EFI and could thus have done whatever nasty things he wanted on the system. And as long as the system is not rebooted, nothing can prevent it to do so. From this, I came to the conclusion that secure boot only provides additional security when the administrator discover the flaws, either via a CVE/DSA/whatever announce, or because he realized the system is having a strange behavior (ex: something suspicious in the logs). Then, he will try to patch the flaw by upgrading its kernel and want to be sure at reboot that the malware didn't manage to infect the patched kernel in the mean time. In other words, the administrator want to be sure at reboot that the problem is solved (at least for this flaw, there could be other flaws of course but they need to be found). If I understood all this correctly and that my conclusions are correct then I believe there could be an interest the secure boot functionality. Don't get me wrong, I'm really concerned about all the side effect of this technology with regards to locked down systems. There is an important need to both be able to disable secure boot and to be able to change and add main/CA keys. But there is nothing we can do technically about this. ==== Implementation ==== So the first question is wether we play secure boot or not. I believe that by playing it we don't remove anything to the users. No matter we play it or not, they will not be free to install whatever software they want as long as secure boot is activated (and this become a "forever" on ARM systems with windows certified logo). But by providing a signed image of Debian we provide at least a bit more security for people with secure boot enabled. Second question is with what key to sign Debian image and our bootloader. Should we use Microsoft key or use our own key and ask the users who wants to benefit from secure boot to install the Debian key. I personnally don't like the idea of using the key of Microsoft as we give them a switch to prevent Debian systems from being booted. On the other hand, I don't know if it will be easy to install new CA keys. At last, there is the question of what to sign. If we want secure boot to be really useful then we should sign all the way from the bootloader to the kernel modules. Thoughts about this? Best regards.
Attachment:
signature.asc
Description: This is a digitally signed message part.