From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SoNi4-0006o1-6a for mharc-grub-devel@gnu.org; Mon, 09 Jul 2012 19:49:44 -0400 Received: from eggs.gnu.org ([208.118.235.92]:58070) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoNi1-0006ni-9R for grub-devel@gnu.org; Mon, 09 Jul 2012 19:49:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SoNhz-00012R-Br for grub-devel@gnu.org; Mon, 09 Jul 2012 19:49:40 -0400 Received: from mail-wi0-f177.google.com ([209.85.212.177]:50007) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoNhz-00012G-20 for grub-devel@gnu.org; Mon, 09 Jul 2012 19:49:39 -0400 Received: by wibhm11 with SMTP id hm11so2587144wib.12 for ; Mon, 09 Jul 2012 16:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ULzMx7sLC0oMAEsQTnLmQCMmEXRYjPoxYLYs30MoC/g=; b=hlSzgPBJBkFvwqs+3mNtOwEKVyCTLA6kASCJghC/fJ+lL700Tgb6riM/OD2owrF7SO Gh+me2kJmLmIomrGgcWSiPK5FqB0uISM6HJ+jauiRbpe/+VqSegCzPZOAv9fx2tAlJLg vF6MbVEO1Jq9/4DmxffCdYEALxwzqVTzfaWKG0WaM1n4BdX0war3PACf1ArQ4H9tBng1 mRq88wC4munH9/wIDpvxGhNAnHwkQZiCc6nKmYSMYvfTJd1MYF3KMMHeMdTElKH4+mdm ElKpj7vST8bn1wgvmJcC/b7gS3hp9SW5FJ4CtTXBc3nJpunjIAi1As2/+hxoO86Tj3v8 OHkQ== Received: by 10.216.209.8 with SMTP id r8mr17991401weo.51.1341877775944; Mon, 09 Jul 2012 16:49:35 -0700 (PDT) Received: from [192.168.178.55] (p5091D557.dip.t-dialin.net. [80.145.213.87]) by mx.google.com with ESMTPS id ch9sm38614568wib.8.2012.07.09.16.49.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jul 2012 16:49:35 -0700 (PDT) Message-ID: <4FFB6E0D.6090607@googlemail.com> Date: Tue, 10 Jul 2012 01:49:33 +0200 From: Andreas Born User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: Secure Boot. Why don't you take the wind out of their sails? References: <1341873508.37363.YahooMailNeo@web171405.mail.ir2.yahoo.com> In-Reply-To: <1341873508.37363.YahooMailNeo@web171405.mail.ir2.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.212.177 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 23:49:42 -0000 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