Re: Secure Boot. Why don't you take the wind out of their sails?

[address@hidden]

>> However, your short easy-to-understand summary is incorrect.  The
>> bootloader password doesn't protect against malware, and it offers
>> only a little protection against "anybody taking over your computer".
>> In fact, if some malware rewrote the grub configuration file, it could
>> be quite annoying to recover.
>
> No, you're incorrect. The password is stored IN the grub configuration file.
> So if that person can rewrite the grub configuration file it can rewrite the
> password too (or fully disable it or ...). Thus that protection becomes
> fully INEFFECTIVE. Even if the password were stored in a separate file that
> file could be changed just as well.

You just made my point ;)  Malware can change the bootloader password,
since it's simply stored in a file, making you jump through quite a
number of hoops before being able to use your computer again.


[snip]

>> Finally, the secure boot initiative isn't a threat to open source
>> operating systems.  The computer administrator has to install a signed
>> OS and then enable signature verification in the firmware.  All
>> systems ship with verification disabled, and all the major motherboard
>> manufacturers have indicated that secure boot will always stay an
>> opt-in mechanism.  And even then, the firmware setup utility can be
>> used to once again disable verification, so it isn't even a hindrance
>> to resale of used equipment, as long as the sale is authorized and the
>> configuration is changed.  It might create some barrier to use of
>> stolen equipment, but even then it is likely that clearing the NVRAM
>> by removing the backup battery will gain access.
>
> Nobody's saying that the basic technology which is not exactly new either is
> a threat. But the implementation SecureBoot is. You're misinformed. While on
> x86 systems there's a switch required to disable SecureBoot that same switch
> is NOT ALLOWED for ARM systems
> (https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/restricted-boot-comic-contest-defend-user-freedom-on-tablets-and-smartphones).
> Please get your facts straight.
> Apart from that even if there is a switch the question remains how easily
> accessible it is going to be? How obvious the need to use it is going to be?
> You're the guy asking for stuff to be simple so that point should be clear
> to you.

Uh no, I'm not "that guy".  I was calling out "that guy" on his claim
that a bootloader password protects against malware, while trying to
be very clear that it isn't the idea of a simple explanation I object
to, but the fact that accuracy was sacrificed.  I was in a meeting
between reading the OP and the time my response went out, I didn't see
the other replies.

>
>> Full-disk encryption
>> is still the best safeguard in case physical security is compromised.
>
> There's still some code loaded and executed before opening the volume. That
> code is responsible for initially decrypting the volume and loading
> something else from within it. Now I say "decrypt" so that means that code
> needs to get credentials from somewhere and if that code were malicious it
> would be given the credentials (as it would appear no different to the user)
> and could use them for anything. No way getting around verification of the
> code unless you have a firmware that supports booting from that volume
> directly but then again the firmware needs to be verified by some means too.
> Imagine you're giving a party and want some sort of entry control. As long
> as you don't verify somebody (code) to be trusted to execute the entry
> control by checking everybody's invite (credentials), there's no way to have
> it invites-only. If you're lacking credentials it won't work and if the
> doorman are untrusted they could not be checking the invites/credentials
> properly. You can't get rid of either one of them completely.

Where did I say otherwise?