[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: EFI in Debian

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.

Reply to: