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 6RsCeuIe4l5t for ; Tue, 23 Aug 2011 22:52:35 +0200 (CEST) Received: from mail-ew0-f50.google.com (mail-ew0-f50.google.com [209.85.215.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Tue, 23 Aug 2011 22:52:35 +0200 (CEST) Received: by ewy10 with SMTP id 10so272268ewy.37 for ; Tue, 23 Aug 2011 13:52:35 -0700 (PDT) Message-ID: <4E541311.6090809@gmail.com> Date: Tue, 23 Aug 2011 22:52:33 +0200 From: Olivier Sessink MIME-Version: 1.0 References: <4E536F5E.7020003@gmail.com> <20110823130508.GB21623@tansi.org> In-Reply-To: <20110823130508.GB21623@tansi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] unlocking dm-crypt from grub - kernel in crypted volume List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 08/23/2011 03:05 PM, Arno Wagner wrote: > > Quite frankly, I doubt this increses security significantly. > > An attacker could just manipulate the grub image and pretend to > do decryption while really loading a compromised kernel. > It would also be possible to patch grub so that it runs a > kernel-patcher after decryption and before starting the kernel. > > I think both options are not really more difficult than > patching a not encrypted kernel. > > The bottom line is still that if an attacker has access and > then you continue to use your computer, you are screwed. > Disk encryption only protects you if you know that the > attacker had access, e.g. when your laptop is stolen. If > you do not realize an attacker had access, anything is > possible. from a theoretical point of view I agree with you. However, given that the attacker does not yet know which kernel is going to be started, has very limited space for attack code, and has to change something (grub) that needs to change the next thing (kernel) instead of directly changing the kernel, it's really more difficult in my opinion. It's beyond the level of a regular good C programmer I would say, while changing the kernel is something any good C programmer should be capable of. Given that this is the most common setup (kernel in unencrypted /boot and the rest of the OS in dm-crypt volume) I think it would be worthwhile to make this setup work in a smooth way (but I can understand it is a lot of work and people don't have the time to do it). Olivier