From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Hm52RILE7kX for ; Wed, 20 Nov 2013 10:09:24 +0100 (CET) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Wed, 20 Nov 2013 10:09:24 +0100 (CET) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vj3ml-0008It-NM for dm-crypt@saout.de; Wed, 20 Nov 2013 10:09:23 +0100 Received: from c-50-132-41-203.hsd1.wa.comcast.net ([50.132.41.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Nov 2013 10:09:23 +0100 Received: from eternaleye by c-50-132-41-203.hsd1.wa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Nov 2013 10:09:23 +0100 From: Alex Elsayed Date: Wed, 20 Nov 2013 01:09:11 -0800 Message-ID: References: <1384831653.18771.33.camel@heisenberg.scientia.net> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit Subject: Re: [dm-crypt] Integrate cryptsetup in bootloader List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de Christoph Anton Mitterer wrote: > On Tue, 2013-11-19 at 09:20 +0700, Trinh Van Thanh wrote: >> Unencrypted boot partition is not safe for some special requirements. >> So I want to increase the secure level for full disk encryption using >> dm-crypt. Can I integrate cryptsetup in bootloader (example GRUB2) or >> is there any other solutions? > > Integrating it in the bootloader doesn't really help you since then the > bootloader is the weak point. > > In the end you'll always need an unencrypted kernel/initrd/bootloader... > so what one can do is booting from a USB stick,.. which you have always > with you... and then have a fully encrypted root-fs. Integrating with the bootloader isn't a _solution_, but it is a _mitigation_. If you're using GRUB2 in a traditional (non-EFI) boot configuration, you can get away with leaving VERY little space for an attacker to work in. In particular, the space before the protective MBR (which is filled by grub's core, and not especially useful to tamper with) and the BIOS Boot Partition it uses to store the more full image (EF02 in gdisk). By creating a truly minimal grub image (cryptdisk, your boot filesystem driver, the linux loader, maybe a couple other things) in which every part is necessary to the boot process, and placing the BBP at the end of the disk, you can force the partition to be the exact minimal size that will hold that data by resizing the LUKS partition. That way, tampering in a manner that WON'T cause the boot process to fail entirely becomes exceedingly difficult, and something with sufficient complexity to patch the kernel becomes prohibitive. I used to use GRUB2's cryptdisk support for a while, and while it was tetchy to work with it does function - if one is familiar with GRUB2's scripting syntax, coreboot's (very) brief overview is sufficient: http://www.coreboot.org/GRUB2#LUKS_disks_openning