|
| From: | Andreas Born |
| Subject: | Re: Secure Boot. Why don't you take the wind out of their sails? |
| Date: | Tue, 10 Jul 2012 03:51:46 +0200 |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 |
Am 10.07.2012 03:23, schrieb address@hidden:
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?
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.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.
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.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.
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.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.
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.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 <address@hidden> 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 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 address@hidden https://lists.gnu.org/mailman/listinfo/grub-devel_______________________________________________ Grub-devel mailing list address@hidden https://lists.gnu.org/mailman/listinfo/grub-devel
| [Prev in Thread] | Current Thread | [Next in Thread] |