Re: [dm-crypt] advice on encrypted snapshots

[Luca Berra <bluca@comedia.it>]

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
  / \