>> 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? _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
