From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Sun, 27 Jun 2010 10:35:41 +0200 (CEST) Message-ID: <4C270D56.7050901@redhat.com> Date: Sun, 27 Jun 2010 10:35:34 +0200 From: Milan Broz MIME-Version: 1.0 References: <1277553580.29791.40.camel@fermat.scientia.net> <20100626125223.GA26185@tansi.org> <1277562112.3245.40.camel@fermat.scientia.net> <20100626183632.GA30731@tansi.org> <4C2653EB.2090606@redhat.com> <1277593981.3239.80.camel@fermat.scientia.net> <20100626233458.GC2304@tansi.org> <20100627002048.GC10187@pc21.mareichelt.com> In-Reply-To: <20100627002048.GC10187@pc21.mareichelt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] FYI: how to (really) cleanly shutdown the system when root is on multiple stacked block devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: markus reichelt Cc: dm-crypt@saout.de On 06/27/2010 02:20 AM, markus reichelt wrote: > * Arno Wagner wrote: > >> Hmm. You know, encrypted root is a problem and pretty difficult to >> do in the rfirt place. Why not just encrypt the critical parts, >> like /var /home /root? The rest only holds binaries and config >> files anyways, which are not that sensitive... > > Are you serious? Usually encrypting everything is better, otherwise we add many problems here. Just to randomly pick two of them: - User must think and know which data are sensitive and avoid to copy them to unencrypted space. It can happen even without his knowledge - temporary file somewhere, coredump, whatever. - using "social engineering" how many people will set the same password to disk encryption and his account? If I have /etc/shadow visible, why I should bother with attacking disc encryption with all its barriers? I'll run dictionary search for passwords there, pretty good tools already here. ... I think that for laptop, encrypting everything is better. And I expect that after clean shutdown my machine is safe. All used tools currently providing methods how to do it properly (I mean dm-crypt/LUKS, loop-aes or Truecrypt). It is just about properly written init/shutdown scripts. I do not think it is so complicated to fix it - just reverse initramfs root-fs mapping. Several similar parts of problems "cutting own throat" are there (like pvmove on root-fs in LVM, multipath solving the situation when all paths to underlying device are temporarily gone). This is nothing completely new. (And yes, I a quite intentionally hijacked this thread to focus on this shutdown & encrypted root-fs problem, sorry:-) Milan