On Tue, Jan 29, 2019 at 03:48:01PM -0800, Gordon Messmer wrote:
On 1/27/19 6:47 PM, Wolfgang Pfeiffer wrote:
[ .. ]
It sounds like you're unfamiliar with the implementation, and possibly
with filesystems and block devices in general. I'll try to explain,
with some simplifications. You suggested this command:
cryptsetup open --type plain -d /dev/urandom
/dev/<block-device> to_be_wiped
This creates a mapping in the kernel where blocks on the virtual
device named "to_be_wiped" are filtered through an encryption
algorithm before writing, or after reading, blocks on the physical
device /dev/<block-device>.
Running this command (unless I'm misreading the docs for the "plain"
section) doesn't actually write to or modify the content of the block
device at all. Only when you write to /dev/mapper/to_be_wiped will
encrypted data actually be written to /dev/<block-device>.
Seems you are right: I've tested it on a USB flash drive, with ext4 on
it and a few files. After running the command above
"cryptsetup open --type ..." targeting that drive, the files on it
were not overwritten but still there: mounting the drive the usual way
just showed me exactly that ..
So the warning cryptsetup is giving here:
-------------
cryptsetup open --type plain -d /dev/urandom /dev/sdd dmcrypt.test
WARNING: Device /dev/sdd already contains a 'ext4' superblock signature.
WARNING!
========
Detected device signature(s) on /dev/sdd. Proceeding further may damage existing data.
[ .. ]
-------------
is technically correct (*may* damage ..) - but chances seem to be
extremely good the data on the targeted drive are still alive - So the
warning might give the user an unjustified sense of security.
(You would normally create a new filesystem on
/dev/mapper/to_be_wiped, which would replace a small number of blocks
on the disk with new blocks containing encrypted data related to the
filesystem. Again, most of the pre-existing data isn't overwritten by
that process. The old data would not be readable through
/dev/mapper/to_be_wiped, but could be directly through
/dev/<block-device>.)
Understood, I think ..
The next step of the process you suggested was:
cat /dev/zero > /dev/mapper/to_be_wiped
This will write zeros to the virtual block device, which will be
filtered through the encryption algorithm and the results written to
the blocks on the physical device. This will sequentially overwrite
the contents of the physical disk.
In other words: It seems the file system is encrypted, not the data:
see the already mentioned FAQ: "Create the LUKS container" - at the
end of the section: "Done. You can now use the encrypted file system
to store data"
The command you referenced above doesn't use LUKS, but that's a minor nit.
Both the filesystem and your data are encrypted when using dm-crypt
(whether you use LUKS or not). However, creating a dm-crypt device
doesn't modify the pre-existing data. It only writes encrypted data
to the disk when data is written to the virtual device.
Provided it works: yes. I had situations where I first ran
cryptsetup open --type plain -d /dev/urandom /dev/<block-device> to_be_wiped
then
cat /dev/zero > /dev/mapper/to_be_wiped
or something similar like
dd if=/dev/zero of=/dev/mapper/to_be_wiped bs=1M status=progress
and the data on the targeted drive were still there. No idea whether
this happened because of faulty hardware or because of a software bug,
or whatever. A sign that something like "cat /dev/zero .. " doesn't
write encrypted data to the physical drive might be that the command
finishes after only a few seconds (didn't take ten secs here, IIRC)
One last "cat /dev/zero .." worked 'tho after closing "gnome-disks",
which previously ran while issuing the cat or dd command.
And the reason I tell that is not to open a debate about why cat or dd
commands didn't work in that situation. It's just a reminder to be
careful if a user is trying to secure their data this way.
Does that make sense?
Definitely: Thank you very much for your time and the effort to
explain all this.
Regards,
Wolfgang
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
