:: Re: [DNG] UEFI and Secure Boot
トップ ページ
このメッセージを削除
このメッセージに返信
著者: John Franklin
日付:  
To: marc
CC: dng
題目: Re: [DNG] UEFI and Secure Boot

> On Oct 23, 2017, at 5:34 PM, marc <marcxdv@???> wrote:
>
>> katolaz@??? writes:
>>> And what if you want to use your own unsigned bootloader? Why should
>>> you ask someone else the permission to boot your own machine? o_O
>>
>> Because I want deny people with physical access the ability to boot unsigned
>> bootloaders.
>>
>> I am both the owner of my hardware and the person who usually has physical
>> access. Requiring signed boot loaders is way to transfer rights from latter
>> role to someone else ??? in my case I'd prefer to transfer them to the
>> former for all portable hardware, so for my next laptop I'm going to do the
>> MOK stuff described on this list last week.
>
> So I might be missing something, but I really don't get the point of
> having a signed boot infrastructure for the technically competent
> computer owner.
>
> If you want to prevent somebody from booting some random unsigned
> code, then a BIOS from 1999 will do: You just configure the
> BIOS to boot your selected internal disk only and then set a password on
> the BIOS and the bootloader. Then nobody can insert a memory stick and boot
> their evil code.


The threat is a rootkit: something that installs a new bootloader and/or kernel and/or kernel module that runs a keylogger or a C&C server or malware server or something. The compromised kernel filters the results of certain system calls to hide the interlopers presence, so you, the “owner” of machine, are unaware they are there, even as root. A BIOS password won’t stop that.

> If your threat model includes somebody who is capable of opening
> your computer and messing with its internals, then no amount
> of EFI will protect you - the bad guy can just replace your
> entire motherboard.


Physical security of the machine is a different layer, but signing kernels can frustrate the Bad Guy. If they swap out the MB for one without a key, that is detectable by the end user. If they swap out the MB with one that has their keys and not yours, you won’t be able to boot the next kernel you sign and install -- again, detectable.

That’s assuming they can get a MB in there that has the same serial numbers (see dmidecode).

> If you are worried that somebody who has
> compromised your OS remotely will hack your bootloader, then
> reconsider their motives: They are already on a running host OS
> as root and can look inside your encrypted disk volumes too -
> you have lost already.


Secureboot is there to prevent someone who has root access from installing a rootkit. (see above) “Looking inside” is bad enough, and kernel signing won’t prevent a Wordpress security flaw from letting them in. It keeps them from compromising the kernel, the tool you rely on to see they are there.

> As far as I can tell, signed bootloaders have advantages
> for people who need to roll out images to remote PCs via
> untrusted channels, and are worried that the people sitting
> in front of their PCs will install the "wrong" kernel. In other
> words, microsoft, large corporates and maybe even some linux
> distributions.


Yes, that is an advantage for them: making sure the kernels that are installed are the kernels they ship, and not something from a malware site or MitM’d during the update. Their tech support crew can easily tell the kernel is the right one because they can verify the signature. They’re producing a product just as Devuan is. It makes sense they would want to protect it, and kernel signing is a good tool for that purpose.

> However, for those weirdos who like to own the computer
> they sit in front of, there is no benefit. Only downside:
> The kernel that enthusiasts build themselves is the "wrong" one to
> those who wish to lock down the computing world with DRM and
> related nonsense.


Since (as has been posted) you can sign your own kernels, the enthusiast can do the same thing corporate tech support can do: verify no one has updated his kernel on him with one he didn’t build. Installing a MOK (Machine Owner Key) in the firmware and removing the keys that shipped with the machine ensures that the enthusiast truly owns the machine.

jf
--
John Franklin
franklin@???