Date: Sun, 9 Jul 2017 22:33:40 -0700 From: Doug Hardie <doug@mail.sermon-archive.info> To: Matthias Apitz <guru@unixarea.de> Cc: Doug Hardie <doug@sermon-archive.info>, galtsev@kicp.uchicago.edu, "freebsd-questions@freebsd.org Questions" <freebsd-questions@freebsd.org> Subject: Re: Unusual Question Message-ID: <5156E6FD-03AE-4244-B3AB-32007439AD20@mail.sermon-archive.info> In-Reply-To: <20170710052228.GA2338@c720-r314251> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 9 July 2017, at 22:22, Matthias Apitz <guru@unixarea.de> wrote: >=20 > El d=C3=ADa domingo, julio 09, 2017 a las 05:34:06p. m. -0700, Doug = Hardie escribi=C3=B3: >=20 >>>> 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. >>>> _______________________________________________ >>=20 >> 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. >=20 > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5156E6FD-03AE-4244-B3AB-32007439AD20>