[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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?

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 ( 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 <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
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
(see Chapter 30 [Invoking grub-mkpasswd-pbkdf2], page 101) to generate
password hashes.
In order to enable authentication support, the ‘superusers’ environment
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
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
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


Grub-devel mailing list

Grub-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]