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

[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.

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 <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
>