Date: Mon, 10 Jul 2017 08:48:34 +0300 From: Heikki Lindholm <holindho@saunalahti.fi> To: freebsd-questions@freebsd.org Subject: Re: Unusual Question Message-ID: <947af5eb-6d29-51c2-25b8-b183561008c4@saunalahti.fi> In-Reply-To: <5156E6FD-03AE-4244-B3AB-32007439AD20@mail.sermon-archive.info> References: <888578F8-AD68-4993-823C-152789F3C929@mail.sermon-archive.info> <52627.76.193.16.95.1499645892.squirrel@cosmo.uchicago.edu> <BF16E1CF-A889-4734-981E-2B68115FCD3C@mail.sermon-archive.info> <20170710052228.GA2338@c720-r314251> <5156E6FD-03AE-4244-B3AB-32007439AD20@mail.sermon-archive.info>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10.07.2017 08:33, Doug Hardie wrote: > >> On 9 July 2017, at 22:22, Matthias Apitz <guru@unixarea.de> wrote: >> >> El día domingo, julio 09, 2017 a las 05:34:06p. m. -0700, Doug Hardie escribió: >> >>>>> but it gives an not permitted error. The whole thing can crash and >>>>> burn at the end. This is an unmanned site so moving drives is not viable. >>>>> _______________________________________________ >>> >>> Thanks for the info. I've never tried the rm approach, but the dd approach seems to work. After a couple hours the machine became unresponsive and ssh sessions were terminated. I think the drive is now empty. I'd like to be able to get it back to verify, but that won't happen. I still have 3 more systems to do this to. The others will have to wait for awhile as I may still need them for a few more days. >> >> I do not think that this approach worked in the sense of overwriting all >> blocks of the disk. While walking through at some point the kernel will >> miss sectors of the disk, for example of memory mapped files of shared >> libs of other running processes or swapped out memory to disk. And the kernel >> will just crash or halt and you will notice that as terminating ssh session. >> Do not rely on the fact that the (sensitive) information on the disk was >> overwritten. The only secure way is doing this from a system running on >> some other disk and even this would allow to recover information with >> forensic tools reading beside of the tracks. Only physical destruction >> will help, for example burning the thing, as you said. > > The swap space was on this drive so it should be overwritten also. Physical memory will go when the power goes off. It would be nice to be able to get the drive back and see just how much was overwritten, but that is not possible. I don't see why dd would not run to completion. The first test I ran it reported that it had cleared over 300 GB on a 500 GB drive. I may see if I can setup another system here and try that where I can monitor and test the result. Virtualbox would seem like the obvious choice to see what happens. Just set up a system with the same attributes and software versions and the same runtime env (daemons).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?947af5eb-6d29-51c2-25b8-b183561008c4>