grub-devel
[Top][All Lists]
Advanced

[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 01:49:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

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



reply via email to

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