[linux-lvm] Snapshots & data security

[Scott Sullivan]

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 ?

[Zdenek Kabelac]

Post by Scott Sullivan
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

[Stuart Gathman]

Post by Scott Sullivan
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.

[Stuart Gathman]

Post by Scott Sullivan
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.

[Zdenek Kabelac]

Post by Stuart Gathman

Post by Scott Sullivan
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