From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.speedxs.nl (smtp.speedxs.nl [83.98.255.13]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 28 Dec 2009 22:41:35 +0100 (CET) Received: from cort.fakenet (unknown [83.98.244.209]) by smtp.speedxs.nl (Postfix) with ESMTP id 995592D0C9 for ; Mon, 28 Dec 2009 22:41:32 +0100 (CET) Received: from [192.168.0.191] (uitsmijter.fakenet [192.168.0.191]) by cort.fakenet (Postfix) with ESMTP id 4C72BBA03F for ; Mon, 28 Dec 2009 22:41:05 +0100 (CET) Message-ID: <4B3925F0.4050409@gmail.com> Date: Mon, 28 Dec 2009 22:41:04 +0100 From: Olivier Sessink MIME-Version: 1.0 References: <4B3914FB.7060008@gmail.com> <20091228212038.GB2224@maude.comedia.it> In-Reply-To: <20091228212038.GB2224@maude.comedia.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] encrypted root: prevent / detect tampering with kernel / initrd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de Luca Berra wrote: > On Mon, Dec 28, 2009 at 09:28:43PM +0100, Olivier Sessink wrote: >> Hi all, >> >> I was wondering if there are some 'common' ways to prevent tampering >> with the unencrypted kernel and initrd in the case of an encrypted >> root filesystem? If somebody has access to your computer they could >> change the initrd and kernel and make your encryption useless (e.g. >> store the password in /boot, or send it over the network, etc. etc.). >> It shouldn't be too hard to make this at least very difficult. > > I'm sorry if anyone has physical access to the machine, you lose. > there is nothing you can do to prevent it. > If your laptop is stolen and later found, i would not trust typing my > password again booting from that disk. I would boot from a rescue media > or install the disk in another machine and recover the data. > What you suggest only creates a false sense of security and should be > avoided. yes you are 100% right from a perfect security viewpoint. However, we're looking at a "regular user" deployment, and we know that our regular users are not going to look after their devices as good as most IT security professionals will do (they might even carry their password in their wallet, or tell the password over the phone). So our aim is not 100% perfect security, but just "make it (a lot) harder" to get to the data. The data on the devices is interesting enough for a simple hack, but not interesting enough for a very complicated attack (or a physical keylogger or tempest attack). So if we can avoid the simple attacks we have improved the overall security. So in our not-so-perfect world we will loose from a determined hacker anyway. But perhaps we can be safe from the script kiddies. Olivier