From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mrt4S-00073L-Vk for mharc-grub-devel@gnu.org; Sun, 27 Sep 2009 08:41:45 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mrt4R-00072T-In for grub-devel@gnu.org; Sun, 27 Sep 2009 08:41:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mrt4M-0006zg-97 for grub-devel@gnu.org; Sun, 27 Sep 2009 08:41:42 -0400 Received: from [199.232.76.173] (port=38749 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mrt4M-0006zc-55 for grub-devel@gnu.org; Sun, 27 Sep 2009 08:41:38 -0400 Received: from fg-out-1718.google.com ([72.14.220.152]:37487) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mrt4L-000438-LF for grub-devel@gnu.org; Sun, 27 Sep 2009 08:41:37 -0400 Received: by fg-out-1718.google.com with SMTP id e21so453228fga.12 for ; Sun, 27 Sep 2009 05:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=UCi0x2tVobj2farrmy5DTyXntYG1nNe0JiZn35l4rOM=; b=abFi0Ln52m4eIEfstm3I7T9zHs3eNWCD8wwZnmcp0XZFTa2W8/b+gAp0Eile9egW2x r/K9NpGnm/6iq12KKEZRpcZwxMSX6HkdF3Z2RMQ6Csa0fmn4XOeSt55qQQJvUqGm5IXv I6hPDMO4/xZqnAL+twbMmRfXt65GYRxHNfZbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=lpwxey7xdZzJCia1I17qTZCwGmv/mM6YN1bx2Hr0jMpgCoGSa4TiXiYAPLPpziyftp GfKblJOdfsYYFy7f78q5R96CuFwBX+da6Ux5HdTsnutD8DybuXPaqqabbwQqyJaFBAjX /yEmFzTRU06Ym7mBR9rR78FNsC/i786TddZ00= Received: by 10.86.17.4 with SMTP id 4mr2512765fgq.13.1254055295877; Sun, 27 Sep 2009 05:41:35 -0700 (PDT) Received: from ?192.168.1.16? ([81.62.124.34]) by mx.google.com with ESMTPS id d4sm3492639fga.7.2009.09.27.05.41.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 27 Sep 2009 05:41:34 -0700 (PDT) Message-ID: <4ABF5D7D.8060404@gmail.com> Date: Sun, 27 Sep 2009 14:41:33 +0200 From: Vladimir 'phcoder' Serbinenko User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: The development of GRUB 2 References: <20090926085720.GV13423@riva.ucam.org> <4ABE2A10.2010302@gmail.com> <4ABE90AA.2010000@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Protection of boot sector and embedded area X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 12:41:43 -0000 James Courtier-Dutton wrote: > 2009/9/27 Michal Suchanek : > >> Obviously your encryption solution does not encrypt the linux volume >> which you boot using the USB stick so it has no reason to be loaded >> when loading Linux, it can only cause harm by trying to decrypt what >> is not encrypted. >> > You make a assumption that the encryption program would cause harm. It does not. > One specifies which partitions to encrypt/decrypt and it leaves the rest alone. > > It's loaded uselessly. Actually normally there is no reason to encrypt any of the files grub accesses. But authenticating files is needed. (encryption doesn't prevent attacker from modifying files) Encrypting is to keep secret MAC or signatures is to keep unmodified. GRUB and most OSes we support are free software so there is no reason to keep them secret. Even proprietary for kernels you have, the binaries aren't secret. There are two reason full disk encryption exists: 1) "I have everything encrypted" is a good confidence-giving sentence and good for marketing 2) If you encrypt everything you have no risk of forgetting encrypting something (typical examples: swap, /tmp, /var/tmp). This renders the approach fool-proof and easy to configure >> Also as Grub can access the disk drives by various means (BIOS, PCI >> device driver, ...) the encryption software would have to hijack all >> these access paths transparently which I can't imagine happening. >> >> > One would obviously need grub to only use BIOS calls and no direct PCI > device access for it to work together with the whole disc encryption > program in pre-boot stages. The only reason we keep BIOS calls by default is that our own drivers don't work in all configurations. > Alternatively, one would have to add > encryption support into grub itself that is not a good idea. > We have patches to do so. While encrypting a part of bootloader and a kernel isn't security-improving, it renders encrypted configuration easier (no need for separate /boot). So I'm favorable to it. Why do you say it's a bad idea? Signatures in grub are on todo list. > I think that maybe being able to install grub into it's own small > partition instead of the embedded area would be all I would need. > I explained why this "all I need" is problematic > Kind Regards > > James > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > >