From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Tue, 29 Dec 2009 00:00:09 +0100 (CET) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NPOZK-0001ZG-Hz for dm-crypt@saout.de; Tue, 29 Dec 2009 00:00:06 +0100 Received: from r9hh95.net.upc.cz ([78.102.215.95]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Dec 2009 00:00:06 +0100 Received: from zkaspar82 by r9hh95.net.upc.cz with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Dec 2009 00:00:06 +0100 From: Zdenek Kaspar Date: Mon, 28 Dec 2009 23:51:21 +0100 Message-ID: <4B393669.9060808@gmail.com> References: <4B3914FB.7060008@gmail.com> <4B39340B.3030308@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In-Reply-To: <4B39340B.3030308@gmail.com> Sender: news 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 Dne 28.12.2009 23:41, Zdenek Kaspar napsal(a): > Dne 28.12.2009 21:28, Olivier Sessink napsal(a): >> 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 was thinking along the lines of: >> - check a checksum of the MBR and partition table >> - check a checksum of the complete /boot filesystem >> - check the pointers in the kernel system call table (detects many >> rootkits) >> - check for virtualization (any virtual rootkits) >> - ...? any better ideas how to detect tampering? >> >> Obviously all of this should be done by a binary inside the encrypted >> filesystem - everything in /boot (kernel and initrd) is not to be >> trusted. That means we can only warn the user after the password is >> probably gone already, but this is better than nothing. >> >> Any comments, ideas or links ? >> >> regards, >> Olivier > > Hi Olivier, > > If you think someone had access to your hardware then you should avoid > running untrusted/modified kernel, initrd and bootloader at all. > > The checksum approach looks fine to me when it's done with binaries from > trusted LiveCD/USB environment - http://www.sysresccd.org/ > > For /boot and bootloader might be efficient: > $ dd ... | sha512sum > > If you're really paranoid then you should remove the drive and > investigate on another machine....... annoying. > > HTH, Z. > > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt Just check the critical files on /boot + bootloader.