Re: Secure Boot. Why don't you take the wind out of their sails?
On Tue, Jul 10, 2012 at 11:29:21AM -0500, Bruce Dubbs wrote: > For people who are not experts, trying Linux or another operating > system becomes much more intimidating. They have to go into the > BIOS and change something. Then, to go back to Windows, they have > to do it again. No windows boots fine without the secure boot enabled. > Will this discourage users from trying something else? You bet. Oh that's for sure. That part is clearly on purpose. :) > But is is for private computers. My LUG frequently gives out DVDs > with various Live system and say try it. That will become much more > problematic. > > I still don't know how someone is supposed to be able to boot > Windows within a VM with this new paradigm. Windows will work fine without secure boot, it just won't have the malware protection secure boot is supposed to offer. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Secure Boot. Why don't you take the wind out of their sails?
richardvo...@gmail.com wrote: Maybe I'm missing something, but when I read this, it doesn't say the hardware must have Secure Boot enabled by default. Rather, it must be enabled by the OEM as part of the Windows preinstallation process, so that it's enabled when it reaches the end user. System builders are still going to purchase UEFI Secure Boot-capable motherboards with Secure Boot disabled-by-default, and they will "just work" if you want to install Linux. For people who are not experts, trying Linux or another operating system becomes much more intimidating. They have to go into the BIOS and change something. Then, to go back to Windows, they have to do it again. Will this discourage users from trying something else? You bet. End-users who bought pre-installed Windows will have to change the configuration option in system setup, which for someone planning to install a new OS from scratch is not a major hurdle. It will be a minor road bump for people using live-CD style media (including USB), but won't be a showstopper if the user actually has permission from the computer owner to boot the alternate media. What likely is that it will prevent unauthorized (by the owner) rebooting public computers using alternate media, but that's not exactly a valid scenario to begin with. But is is for private computers. My LUG frequently gives out DVDs with various Live system and say try it. That will become much more problematic. I still don't know how someone is supposed to be able to boot Windows within a VM with this new paradigm. -- Bruce ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Secure Boot. Why don't you take the wind out of their sails?
On Tue, Jul 10, 2012 at 12:04 AM, Chris Murphy wrote: > > On Jul 9, 2012, at 7:23 PM, richardvo...@gmail.com wrote: >> All >> systems ship with verification disabled, and all the major motherboard >> manufacturers have indicated that secure boot will always stay an >> opt-in mechanism. > > This is mystifying because it directly contradicts the Microsoft Windows > hardware certification requirements, which require that to get the made for > Windows 8 certification, the hardware must be UEFI, must implement Secure > Boot, must have it enabled by default (except servers), and must have a > Microsoft key included. It also requires a user chooseable option to disable > Secure Boot on x86, but not ARM. Maybe I'm missing something, but when I read this, it doesn't say the hardware must have Secure Boot enabled by default. Rather, it must be enabled by the OEM as part of the Windows preinstallation process, so that it's enabled when it reaches the end user. System builders are still going to purchase UEFI Secure Boot-capable motherboards with Secure Boot disabled-by-default, and they will "just work" if you want to install Linux. End-users who bought pre-installed Windows will have to change the configuration option in system setup, which for someone planning to install a new OS from scratch is not a major hurdle. It will be a minor road bump for people using live-CD style media (including USB), but won't be a showstopper if the user actually has permission from the computer owner to boot the alternate media. What likely is that it will prevent unauthorized (by the owner) rebooting public computers using alternate media, but that's not exactly a valid scenario to begin with. ARM is a red herring, IMO. Pretty much all ARM processors include some sort of code security module that blocks external access to the bootloader without the correct reprogramming key. This is pretty standard for embedded systems, and has been for decades. Most embedded systems aren't designed to boot from removable media. Most tablets don't give the end user root privilege. That's a shame, and something we should work to fix, but going around telling everyone that the world will end if Microsoft gets Secure Boot onto media devices is just dishonest. Those devices have been locked down already, and the world didn't end. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Secure Boot. Why don't you take the wind out of their sails?
On Jul 9, 2012, at 7:23 PM, richardvo...@gmail.com wrote: > All > systems ship with verification disabled, and all the major motherboard > manufacturers have indicated that secure boot will always stay an > opt-in mechanism. This is mystifying because it directly contradicts the Microsoft Windows hardware certification requirements, which require that to get the made for Windows 8 certification, the hardware must be UEFI, must implement Secure Boot, must have it enabled by default (except servers), and must have a Microsoft key included. It also requires a user chooseable option to disable Secure Boot on x86, but not ARM. Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Secure Boot. Why don't you take the wind out of their sails?
>> 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
Re: Secure Boot. Why don't you take the wind out of their sails?
Am 10.07.2012 03:23, schrieb richardvo...@gmail.com: I'll decloak to offer my response, but please remember that I'm not one of the developers so my opinion is of limited value. By the same token, I've been recognized by Microsoft for community contributions, but I do not work for them and do not speak for them. First, putting things in simple language is very positive and necessary. Did anybody comment on or deny it? 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. Also, the bootloader password solves a very different problem from the secure boot initiative. The grub password check doesn't verify integrity of system files. Yes, that's the point. As they are not related one can't do the job of the other one unlike what you suggest in your initial mail. 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. 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. So definitely, this sort of thing needs to be summarized and then explained in detail using plain English that can be understood by those who aren't so technically astute. But lets not sacrifice accuracy in the desire to use simpler words. Ben Voigt On Mon, Jul 9, 2012 at 5:38 PM, Graham Cunnington wrote: Subject: Secure Boot. Why don't you take the wind out of their sails? (1) Now is the time to move quickly. The development needs to be short and clear so that even a beginner can use it immediately. (2) The Problem: Microsoft and allied companies have an idea to force a Microsoft (Verisign) key on to hardware manufacturers which may be an attempt once again to bring in anti-competitive practices and may decrease the uptake of Linux systems. The "Secure boot key" proposed could in fact limit consumer choice and drag Grub2 into a fight none of its making. (3) The Problem of Verbosity: Grub2 already has the solu
Re: Secure Boot. Why don't you take the wind out of their sails?
I'll decloak to offer my response, but please remember that I'm not one of the developers so my opinion is of limited value. By the same token, I've been recognized by Microsoft for community contributions, but I do not work for them and do not speak for them. First, putting things in simple language is very positive and necessary. 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. Also, the bootloader password solves a very different problem from the secure boot initiative. The grub password check doesn't verify integrity of system files. 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. Full-disk encryption is still the best safeguard in case physical security is compromised. So definitely, this sort of thing needs to be summarized and then explained in detail using plain English that can be understood by those who aren't so technically astute. But lets not sacrifice accuracy in the desire to use simpler words. Ben Voigt On Mon, Jul 9, 2012 at 5:38 PM, Graham Cunnington wrote: > Subject: Secure Boot. Why don't you take the wind out of their sails? > > (1) Now is the time to move quickly. > The development needs to be short and clear so that even a beginner can use > it immediately. > > (2) The Problem: > > Microsoft and allied companies have an idea to force a Microsoft (Verisign) > key on to hardware manufacturers which may be an attempt once again to bring > in anti-competitive practices and may decrease the uptake of Linux systems. > The "Secure boot key" proposed could in fact limit consumer choice and drag > Grub2 into a fight none of its making. > > (3) The Problem of Verbosity: > > Grub2 already has the solution to protect Grub and therefore the kernels > that Grub boots, but that solution is currently unavailable because Grub > developers have no idea how to KISS. > > Keep It Simple Silly. Long-winded geeky sentences have no place in Grub. > > "in some environments, such as kiosks, it may be appropriate to lock down > the boot loader to require authentication before performing certain > operations. > The ‘password’ (see Section 14.3.33 [password], page 62) and > ‘password_pbkdf2’ (see > Section 14.3.34 [password pbkdf2], page 62) commands can be used to define > users, each > of which has an associated password. ‘password’ sets the password in plain > text, requiring > ‘grub.cfg’ to be secure; ‘password_pbkdf2’ sets the password hashed using > the Password- > Based Key Derivation Function (RFC 2898), requiring the use of > grub-mkpasswd-pbkdf2 > (see Chapter 30 [Invoking grub-mkpasswd-pbkdf2], page 101) to generate > password hashes. > In order to enable authentication support, the ‘superusers’ environment > variable > must be set to a list of usernames, separated by any of spaces, commas, > semicolons, pipes, > or ampersands. Superusers are permitted to use the GRUB command line, edit > menu > entries, and execute any menu entry. If ‘superusers’ is set, then use of the > command line > is automatically restricted to superusers." > > The above is incomprehensible to most users who are not developers. Why not > just say: > > "You can password-protect Grub. This will secure it against malware and > anybody taking over your computer." > > > (4) The Solution: > > (a) Insert into the standard Grub Menu a link which says: Set a password on > Grub, which when clicked allows the user to do so. > > (b) If this has already been done, then on switching on the computer, the > password dialog box should pop up prior to the boot Menu. > > (c) If this is done then we already have Secure Boot and the administrators > of companies and home computers will have protected their computers and the > Microsoft initiative becomes unnecessary, at least for Secure Boot (Secure > Bios is another matter
Re: Secure Boot. Why don't you take the wind out of their sails?
Am 10.07.2012 00:38, schrieb Graham Cunnington: The above is incomprehensible to most users who are not developers. Why not just say: "You can password-protect Grub. This will secure it against malware and anybody taking over your computer." This is in no way comparable to Secure Boot or TPM measure in general. A password just prevents THIS instance of grub and THIS grub configuration from being used to boot systems in an unintended manner by unauthorized individuals. It can be easily circumvented by e.g. booting from a CDROM or USB drive (hardware access is the key here). Password-based menus are inherently insecure when used with physical access. It's commonly described as security by obscurity. Just locking the one most obvious entry in a secure manner doesn't make the whole building safe if there are other slightly hidden, unlocked entries. Security AND obscurity combined can offer additional security (e.g. all doors locked and hidden). Furthermore password-based menus don't prevent that installation of grub to be replaced by a malicious modified instance of grub which could e.g. log your password and could load a maliciously modified kernel. That's because unlike other measure like Secure Boot it does not verify the code executed. Instead you're just trusting the code to correctly verify the password and it does not even check the kernel. To be protected against malicious code there needs to be a secure component that checks every code executed by the computer at any point for trustworthiness. That's simply put and sort of an optimal scenario. In reality you won't be able to check more than a sensible selection for administrative reasons (except for clearly defined use cases like some embedded devices) and it's somewhat more complicated. So we have two completely different use cases here: - passwords: verification of the user i.e. the human individual trying to use that bootloader instance (not anything else), could be ineffective with malicious code which is not checked here - TPM or Secure Boot: verification of the actual code executed i.e. no malicious software is executed if everything is verified (practically impossible) and if nobody is able to get his malicious code trusted due to human or administrative mistakes e.g. AFAIK as with Secure Boot almost nothing is verified the glamorously advertised, all-encompassing, magic protection is actually a fallacy and just very limited. If it weren't for the seemingly obvious true concerns of global companies, it could actually be quite an interesting technology. Andreas Born ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Secure Boot. Why don't you take the wind out of their sails?
On Jul 9, 2012, at 4:38 PM, Graham Cunnington wrote: > > "You can password-protect Grub. This will secure it against malware and > anybody taking over your computer." Because it's an untrue statement. It is not the same thing as key-signing a boot loader. While GRUB2's UI's can be protected, I can easily cause grub.efi to be replaced with some other bootloader which happens to be malware, or replace the kernel a password protected GRUB2 is set to load with a kernel that contains malware. > e then we already have Secure Boot and the administrators of companies and > home computers will have protected their computers and the Microsoft > initiative becomes unnecessary, at least for Secure Boot (Secure Bios is > another matter and another battle). There is no meaning to secure BIOS. And what you're describing GRUB2 do in lieu of Secure Boot doesn't prevent any of the problems/concerns Secure Boot is supposed to solve. That there are significant negative concerns for how OEM's are going to implement Secure Boot, this is not a compelling argument against Secure Boot or against the real threat of pre-boot malware. Your complaint is with OEMs way more than Microsoft, and way more than GNU GRUB2. Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Secure Boot. Why don't you take the wind out of their sails?
Subject: Secure Boot. Why don't you take the wind out of their sails? (1) Now is the time to move quickly. The development needs to be short and clear so that even a beginner can use it immediately. (2) The Problem: Microsoft and allied companies have an idea to force a Microsoft (Verisign) key on to hardware manufacturers which may be an attempt once again to bring in anti-competitive practices and may decrease the uptake of Linux systems. The "Secure boot key" proposed could in fact limit consumer choice and drag Grub2 into a fight none of its making. (3) The Problem of Verbosity: Grub2 already has the solution to protect Grub and therefore the kernels that Grub boots, but that solution is currently unavailable because Grub developers have no idea how to KISS. Keep It Simple Silly. Long-winded geeky sentences have no place in Grub. "in some environments, such as kiosks, it may be appropriate to lock down the boot loader to require authentication before performing certain operations. The ‘password’ (see Section 14.3.33 [password], page 62) and ‘password_pbkdf2’ (see Section 14.3.34 [password pbkdf2], page 62) commands can be used to define users, each of which has an associated password. ‘password’ sets the password in plain text, requiring ‘grub.cfg’ to be secure; ‘password_pbkdf2’ sets the password hashed using the Password- Based Key Derivation Function (RFC 2898), requiring the use of grub-mkpasswd-pbkdf2 (see Chapter 30 [Invoking grub-mkpasswd-pbkdf2], page 101) to generate password hashes. In order to enable authentication support, the ‘superusers’ environment variable must be set to a list of usernames, separated by any of spaces, commas, semicolons, pipes, or ampersands. Superusers are permitted to use the GRUB command line, edit menu entries, and execute any menu entry. If ‘superusers’ is set, then use of the command line is automatically restricted to superusers." The above is incomprehensible to most users who are not developers. Why not just say: "You can password-protect Grub. This will secure it against malware and anybody taking over your computer." (4) The Solution: (a) Insert into the standard Grub Menu a link which says: Set a password on Grub, which when clicked allows the user to do so. (b) If this has already been done, then on switching on the computer, the password dialog box should pop up prior to the boot Menu. (c) If this is done then we already have Secure Boot and the administrators of companies and home computers will have protected their computers and the Microsoft initiative becomes unnecessary, at least for Secure Boot (Secure Bios is another matter and another battle). (d) do it quickly, keep it simple, keep it smart then tell the world what you have done. Computer journalists will love you for it. Remember, it has to be easy to understand even to people new to computers can quickly set a password on their boot. (5) Who am I? A pemsioner with no background in computing, science or mathematics. I came to computing late and have been using only open-source software for 8 years. I have 2 oldish computers. On one I am multi-bootiong 14 operating systems with Grub2 (13 Linux + Haiku, an experimental modular operating system). Best wishes grahamc___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
