Greatings,
I started reading online to refresh what I knew about secure deletion of files, and being sure that "free space" on an ext3/ext4 partition is surely "free", that is you can't recover the files that _were_ there.
After reading this article:
http://techthrob.com/2009/03/02/howto-delete-files-permanently-and-securely-...
I found that there is a Fedora RPM for srm, and that the source code for sfill is at http://www.thc.org/releases.php
I will (re)study these topics in detail in the next days. My first interest is to understand if those (or other) tools are enough to be sure, without reformatting/reinstalling, that, besides the files one DOES want to keep, there really is nothing else recoverable on the drive.
I'm very interested to know your opinion/experiences/suggestions about this.
TIA, Marco
Am 30.03.2013 12:58, schrieb M. Fioretti:
I will (re)study these topics in detail in the next days. My first interest is to understand if those (or other) tools are enough to be sure, without reformatting/reinstalling
reformat / reinstall does not anything in the direction of the topic
that, besides the files one DOES want to keep, there really is nothing else recoverable on the drive
dd if/dev/urandom of=random.bin bs=16M; sync; rm -f random.bin
creates a file with random-stuff until the disk is full, syncs it really to the disk and removes the file as the same with dd if=/dev/zero will zerofill free space to make it possible shink thin provisioned virtual-disks as example
On Sat, Mar 30, 2013 13:10:57 PM +0100, Reindl Harald wrote:
dd if/dev/urandom of=random.bin bs=16M; sync; rm -f random.bin
thanks. I assume there should be an equal sign after the "if", right? Anyway:
- shouldn't this be done several times, to make sure that whatever was in the free space really is unrecoverable?
- apart from that, probably it's a mix of typos and English not being my native language, but honestly I don't understand the last two lines of your answer, that is the part after "as the same":
creates a file with random-stuff until the disk is full, syncs it really to the disk and removes the file as the same with dd if=/dev/zero will zerofill free space to make it possible shink thin provisioned virtual-disks as example
may I ask you to rephrase them, please?
Marco
Am 30.03.2013 13:30, schrieb M. Fioretti:
On Sat, Mar 30, 2013 13:10:57 PM +0100, Reindl Harald wrote:
dd if/dev/urandom of=random.bin bs=16M; sync; rm -f random.bin
thanks. I assume there should be an equal sign after the "if", right?
ups - correct
Anyway:
- shouldn't this be done several times, to make sure that whatever was in the free space really is unrecoverable?
yes and no yes in theory no if you need not fear the CIA :-)
creates a file with random-stuff until the disk is full, syncs it really to the disk and removes the file as the same with dd if=/dev/zero will zerofill free space to make it possible shink thin provisioned virtual-disks as example
if you have a virtual machine with growable disks and delete a lot of data the disk will not get smaller, shrink the disk will not really work
after write zeros to the free space in the guest you can successful shrink the virtual disk on the host system
On Sat, Mar 30, 2013 13:41:20 PM +0100, Reindl Harald wrote:
if you have a virtual machine with growable disks and delete a lot of data the disk will not get smaller, shrink the disk will not really work
after write zeros to the free space in the guest you can successful shrink the virtual disk on the host system
ok, now I get what you meant, thanks.
And I also realize I forgot a part in my initial question: how to do the same thing with the swap partition? Would this technique still work or make the system unusable? (as I said, what I'm looking at is how to clean a live, running system, hence the question)
Marco
Am 30.03.2013 13:39, schrieb M. Fioretti:
On Sat, Mar 30, 2013 13:41:20 PM +0100, Reindl Harald wrote:
if you have a virtual machine with growable disks and delete a lot of data the disk will not get smaller, shrink the disk will not really work
after write zeros to the free space in the guest you can successful shrink the virtual disk on the host system
ok, now I get what you meant, thanks.
And I also realize I forgot a part in my initial question: how to do the same thing with the swap partition? Would this technique still work or make the system unusable? (as I said, what I'm looking at is how to clean a live, running system, hence the question)
i do not use any swap partition, not needed on machines with 16 GB RAM :-)
On 30.03.2013, M. Fioretti wrote:
- shouldn't this be done several times, to make sure that whatever was in the free space really is unrecoverable?
One single write/overwrite operation is sufficient. No need for more.
http://link.springer.com/chapter/10.1007%2F978-3-540-89862-7_21
On Sat, Mar 30, 2013 at 12:58:31 +0100, "M. Fioretti" mfioretti@nexaima.net wrote:
Greatings,
I started reading online to refresh what I knew about secure deletion of files, and being sure that "free space" on an ext3/ext4 partition is surely "free", that is you can't recover the files that _were_ there.
There are issues that may or may not apply to you depending on what you are really worried about (your threat model). Note for example that disk drives have spare sectors that may have been used for some of your data that you can't directly access. (Though the secure erase function of your disk drive is supposed to erase these sectors as well as the rest of the disk.) If you have a flash based device there is lots of space that you don't have direct access to and gets used regularly (unlike spare sectors on disk drives).
It makes a difference if you are concerned about attacks by users of the machine, people who grab the machine while it is powered on or people who grab it while powered off.
The latter case can be handled well by using encrypted partitions.
If you are worried only about files that used to exist, but don't going forward you may want to consider backing up just the files you want, overwriting the whole disk(s) with something (zeros should be fine) using dd, then invoke the secure erase function of the disk(s). Then reinstall and restore from backup.
On Sat, Mar 30, 2013 09:54:41 AM -0500, Bruno Wolff III wrote:
It makes a difference if you are concerned about attacks by users of the machine, people who grab the machine while it is powered on
The two cases above are exactly what I had in mind, regardless of how frequent/realistic they are. My brain just got stuck on them, I guess, so I started refreshing what I knew on the topic. Any further comment on those cases is welcome.
Marco
On Sat, Mar 30, 2013 at 17:17:52 +0100, "M. Fioretti" mfioretti@nexaima.net wrote:
On Sat, Mar 30, 2013 09:54:41 AM -0500, Bruno Wolff III wrote:
It makes a difference if you are concerned about attacks by users of the machine, people who grab the machine while it is powered on
The two cases above are exactly what I had in mind, regardless of how frequent/realistic they are. My brain just got stuck on them, I guess, so I started refreshing what I knew on the topic. Any further comment on those cases is welcome.
It makes sense to use luks encrypted partitions so that the file systems are not practically accessible once the keys are out of memory. You can also encrypt sensative files separately so that they aren't accessible in some cases where local users are able to get access to the files. If you think an attacker is going to try to read the luks keys from memory you may want to disable firewire to make it harder. If you are looking at possible seizure by people who are likely to try to do that with bad consequences if they do, then you might look at some deadman set ups. Using those risks losing all of your data when you are not under attack, so you need to be careful trying to do something like that. People have also been know to set up physical destruction of disk drives that can be triggered very quickly. Again there is a balancing act between making sure the drives are destroyed before they are seized and inadvertantly destroying them when there isn't a real threat.
Another attack you may need to worry about is the evil maid attack where the computer is accessed and hardware key loggers and the like are attached and then put back where it was, in the hope you will enter keys that will be obtained when the device is accessed again later.
-
Bruno Wolff III -
Heinz Diehl -
M. Fioretti -
Reindl Harald