From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from maude.comedia.it (maude.comedia.it [77.93.254.181]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Sun, 1 Nov 2009 09:06:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by maude.comedia.it (Postfix) with ESMTP id 489AE86F2F for ; Sun, 1 Nov 2009 09:06:48 +0100 (CET) Received: from maude.comedia.it ([127.0.0.1]) by localhost (maude.comedia.it [127.0.0.1]) (amavisd-new, port 10025) with LMTP id uXZi+j3bD3-F for ; Sun, 1 Nov 2009 09:06:48 +0100 (CET) Date: Sun, 1 Nov 2009 09:06:48 +0100 From: Luca Berra Message-ID: <20091101080647.GA2090@maude.comedia.it> References: <1256933154.21609.14.camel@markov.biostat.ucsf.edu> <20091031081240.GA18686@maude.comedia.it> <1257012182.17395.36.camel@corn.betterworld.us> <20091031233947.GA17286@maude.comedia.it> <20091101020531.GA23808@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline In-Reply-To: <20091101020531.GA23808@tansi.org> Subject: Re: [dm-crypt] advice on encrypted snapshots List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Sun, Nov 01, 2009 at 03:05:31AM +0100, Arno Wagner wrote: >One pice of meta-advice may be appropriate: > >Try for simplicity. If you feel your solution is getting >too complex to understand it in one go, try very hard to >find a simpler one. Complex solutions are not only a lot >more likely to fail, the chances for them to be secure >are a lot worse. The solution i proposed at the beginning, encrypt the pv, was the simplest and more secure one, it also prevented any possible leak. Alas it does not work in the op environment, so we have to find a better one. Here comes solution two, snapshot the lv, it is still quite simple, there is the possibility of some information leak, but i don't really believe the cow table and some modified sector are enough material for cryptanalysis. But solution two fails, I can luksOpen either the original lv or the snapshot, but not both at the same time. I have no idea if this is a intended, a bug, or if i am overlooking something obvious. >Incidentially, the ooriginal question was about file >backups, not snapshots. If you want a snapshot and >can afford to umount the device, just use dd. incidentally it was about snapshots, but your advice about dd makes me realize you have no idea what a snapshot is. A snapshot is not a byte-level copy of a disk, id call that a dump. A snapshot is a live image of a block device frozen at the point in time it was taken. A snapshot does not usually need the same amount of disk space as the original, and creation is almost instant. The most common use of snapshots is doing backups while preserving data coherence. If you backup a large data set while an application is active you will find some files will change between the start and end of backup. If the files are related probably having a backup of file A at version 1001 and file B at version 1012 is not what you want. One solution would be stopping the application for the whole time it takes to back-up, but what if we cannot afford the downtime? Enter snapshots: You just have to stop/start your app for the few seconds it would take to snapshot, or maybe your app can quiesce io, or you just cross your finger and go on.... Then you remount the snapshot on a different mount point and do a file level backup of that, as you would do with the original. Third solution was written just to show how complex it is, i did not really mean it, but since two did not work i gave it a try, and found it does not work either. In the form written below it is not even secure, but if it worked it could be improved by encrypting the backing storage of the cow table with a random key, and make the snapshot volatile. That would even negate the info leak we have at two. Regards, L. P.S. sorry for the embarrassing amount of typos in the mail below, but i was really tired. >On Sun, Nov 01, 2009 at 12:39:47AM +0100, Luca Berra wrote: >> On Sat, Oct 31, 2009 at 11:03:02AM -0700, Ross Boylan wrote: >>> On Sat, 2009-10-31 at 09:12 +0100, Luca Berra wrote: >>>> On Fri, Oct 30, 2009 at 01:05:54PM -0700, Ross Boylan wrote: >>>> >Does anyone have any advice about how to snapshot an encrypted volume so >>>> >that the snapshot won't leak information? >>>> > >>>> Do you mean linux-lvm snapshot >>> Yes. >>>> or some storage based one? >>> I'm not sure what that means, but I don't want to rsync or tar. The >> i meant a storage devices which presents disk space as one or more lun >> to a host using either fibre-channel or iscasi or similar means, but >> that's not your case. >>> >>>> In the first case I think the safest way is encrypting the PV. >>> >>> I don't think I can. Here's my setup: >>> V1E encrypted volume, built on top of >>> V1R raw volume, which is part of VGA volume group, composed of >>> PVA physical volume (which is actually software RAID). >>> >> ... >>> >>> So if I snapshot V1E I think I must use VGA (at any rate, I have no >>> other space), which exposes the readable version of my data. >> it fails on me when creating the v1e-snap device, but maybe i am just >> too tired to figure it out now, see below... >> >>> Maybe I could snapshot V1R and use the same encryption key as for V1E to >>> make V2E? >> when i try to luksOpen a snapshot i get "Device Busy" >> and "device-mapper: ioctl: device doesn't appear to be in the dev hash >> table." in dmesg >> >>> Now that I think of it, I'm not even sure if LVM will snapshot the >>> product of dm-crypt (V1E). >> no, you have to do it by hand >> it could be something like: >> >> size=`blockdev --getsize /dev/mapper/v1e` >> cowsize=$(( $size / 2048 * 20 / 100 )) # 20% of v1e size >> chunk=8 >> lvcreate -n v1e-cow -l $cowsize /dev/vga >> dmsetup table v1e | dmsetup create v1e-real >> dmsetup suspend v1e >> echo 0 $size snapshot /dev/mapper/v1e /dev/vga/v1e-cow p $chunk | dmsetup create v1e-snap >> echo 0 $size snapshot-origin /dev/mapper/v1e | dmsetup create v1e-origin >> dmsetup table v1e-origin | dmsetup load v1e >> dmsetup resume v1e >> >> mount /dev/mapper/v1e-snap /wherever >> backup >> umount /dev/mapper/v1e-snap >> >> dmsetup suspend v1e >> dmsetup remove v1e-snap >> dmsetup remove v1e-origin >> dmsetup table v1e-real | dmsetup load v1e >> dmsetup resume v1e >> >> >> -- >> Luca Berra -- bluca@comedia.it >> Communication Media & Services S.r.l. >> /"\ >> \ / ASCII RIBBON CAMPAIGN >> X AGAINST HTML MAIL >> / \ >> _______________________________________________ >> dm-crypt mailing list >> dm-crypt@saout.de >> http://www.saout.de/mailman/listinfo/dm-crypt >> > >-- >Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name >GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F >---- >Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans > >If it's in the news, don't worry about it. The very definition of >"news" is "something that hardly ever happens." -- Bruce Schneier >_______________________________________________ >dm-crypt mailing list >dm-crypt@saout.de >http://www.saout.de/mailman/listinfo/dm-crypt -- Luca Berra -- bluca@comedia.it Communication Media & Services S.r.l. /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \