[linux-lvm] Snapshots & data security

[linux-lvm] Snapshots & data security

[Scott Sullivan]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

Hello,

Could someone please clarify if there is a legitimate reason to worry about
data security of a old (removed) LVM snapshot?

For example, when you lvremove a LVM snapshot, is it possible for data to
be recovered if you create another LVM and it happens to go into the same
area as the old snapshot we lvremoved?

If this helps clarify, do we have to worry about security scrubbing a LVM
snapshot for data security ?

[-- Attachment #2: Type: text/html, Size: 501 bytes --]

Re: [linux-lvm] Snapshots & data security

[Stuart Gathman]

On 07/19/2016 11:28 AM, Scott Sullivan wrote:
>
> Could someone please clarify if there is a legitimate reason to worry
> about data security of a old (removed) LVM snapshot?
>
> For example, when you lvremove a LVM snapshot, is it possible for data
> to be recovered if you create another LVM and it happens to go into
> the same area as the old snapshot we lvremoved?
>
> If this helps clarify, do we have to worry about security scrubbing a
> LVM snapshot for data security ?
Yes, the snapshot LV will contain (obsolete) copies of any sectors
(actually chunks) written to during the life of the snapshot.

However, you still have the live data in the same VG, so it doesn't
present any additional exposure.  Anyone with access to the raw disk can
just read the live LV as well as the snapshot. 

You real question, however, is probably about creating a new LV, and
whether reading that new LV will read old contents of the disk.  
Allocating a new LV only zeros the first 4k of the volume.  Reading the
LV will pick up all the leftover garbage from previous contents - a Very
Bad Thing security wise.   This is arguably a bug. 

Solutions I've seen proposed:

1) use dd to zero the volume after allocating - this is what you should
do today

2) allocate a snapshot of an existing image - this solves the security
problem but has performance problems

3) LVM should have an option to logically zero a new LV - this is simple
in concept, but maybe not so trivial to make bug free.  The LV allocates
a bitmap of all the chunks.  All chunks return zeros until written to. 
A 100G LV with 65k chunks would need only 200K for the bitmap - so the
overhead is quite small.  You could even keep the bitmap in chunks that
have never been written to, with a pointer in metadata, moving it around
as necessary - but that would be even harder to make bug free.

Re: [linux-lvm] Snapshots & data security

[Zdenek Kabelac]

Dne 19.7.2016 v 17:28 Scott Sullivan napsal(a):
> Hello,
>
> Could someone please clarify if there is a legitimate reason to worry about
> data security of a old (removed) LVM snapshot?
>
> For example, when you lvremove a LVM snapshot, is it possible for data to be
> recovered if you create another LVM and it happens to go into the same area as
> the old snapshot we lvremoved?
>
> If this helps clarify, do we have to worry about security scrubbing a LVM
> snapshot for data security ?


lvm2 is 'volume manage'  - not a security tool to obfuscate data on your disk 
- this is 'admins' task.

So if you do care about 'data' content you give to your user in LV - it's
then 'admins' jobs to 'clear-up' all space before LV is given to user.

i.e.   'lvcreate  &&  dd if=/dev/zero....'

lvm2 does not care about 'data' content - it's metadata management tool.

Now if you are paranoid and you care purely about 'erasing' data from your 
snapshot - you can use  'lvconvert --splitsnapshot' and then erase again with 
'dd'  your COW volume you get from split.

Saying all this - you can try to use 'thin-provisioning' instead,
which has built-in option of zeroing  provisioned blocks - so whenever your 
provisioned LV gets a 'new block' - it's unwritten part are always zeroed - so 
there is no 'data-leak'.

And finally - if you are using modern filesystem like ext4 or XFS - they are 
tracking written area - so  'fs' user cannot actually read 'unwritten' data.

And 2nd. finally  - for paronid admin consider 'data' encryption....

Regards

Zdenek

Re: [linux-lvm] Snapshots & data security

[Stuart Gathman]

On 07/19/2016 11:28 AM, Scott Sullivan wrote:
>
> Could someone please clarify if there is a legitimate reason to worry
> about data security of a old (removed) LVM snapshot?
>
> For example, when you lvremove a LVM snapshot, is it possible for data
> to be recovered if you create another LVM and it happens to go into
> the same area as the old snapshot we lvremoved?
>
> If this helps clarify, do we have to worry about security scrubbing a
> LVM snapshot for data security ?
>
Another idea: if your VG is on SSD, and properly aligned, then DISCARD
on the new LV will effectively zero it as far as any guest VMs are
concerned.  (The data is still on the flash until erased by the
firmware, of course.)  If VG and PE size do not align with the SSD erase
block, then you can still zero the "edges" of the new LV, which is much
faster (and less wear on the SSD) than zeroing the whole thing.  You
could always read-verify that the data is actually all zero.

Re: [linux-lvm] Snapshots & data security

[Zdenek Kabelac]

Dne 27.7.2016 v 21:17 Stuart Gathman napsal(a):
> On 07/19/2016 11:28 AM, Scott Sullivan wrote:
>>
>> Could someone please clarify if there is a legitimate reason to worry
>> about data security of a old (removed) LVM snapshot?
>>
>> For example, when you lvremove a LVM snapshot, is it possible for data
>> to be recovered if you create another LVM and it happens to go into
>> the same area as the old snapshot we lvremoved?
>>
>> If this helps clarify, do we have to worry about security scrubbing a
>> LVM snapshot for data security ?
>>
> Another idea: if your VG is on SSD, and properly aligned, then DISCARD
> on the new LV will effectively zero it as far as any guest VMs are
> concerned.  (The data is still on the flash until erased by the
> firmware, of course.)  If VG and PE size do not align with the SSD erase
> block, then you can still zero the "edges" of the new LV, which is much
> faster (and less wear on the SSD) than zeroing the whole thing.  You
> could always read-verify that the data is actually all zero.

Yes - as already suggested -  once you create a new LV -
you can  'blkdicard /dev/vg/lv'

Note - SSD may not always ensure blocks are zeroed - they could just
move trimmed block into reuse list with undefined content.

Anyway - lvm2 is not tool for data protection and it's upto system admin
to ensure there are no data leaks.

So pick the solution which fits best your needs - lvm2 provides all the 
tooling for it.

Regards

Zdenek