Date: Mon, 10 Jul 2017 07:22:28 +0200 From: Matthias Apitz <guru@unixarea.de> To: Doug Hardie <doug@sermon-archive.info> Cc: galtsev@kicp.uchicago.edu, "freebsd-questions@freebsd.org Questions" <freebsd-questions@freebsd.org> Subject: Re: Unusual Question Message-ID: <20170710052228.GA2338@c720-r314251> In-Reply-To: <BF16E1CF-A889-4734-981E-2B68115FCD3C@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--J/dobhs11T7y2rNN Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable El d=C3=ADa domingo, julio 09, 2017 a las 05:34:06p. m. -0700, Doug Hardie = escribi=C3=B3: > >> 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 via= ble. > >> _______________________________________________ >=20 > Thanks for the info. I've never tried the rm approach, but the dd approa= ch 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 t= o 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 m= ay 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 kern= el 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. matthias --=20 Matthias Apitz, =E2=9C=89 guru@unixarea.de, =E2=8C=82 http://www.unixarea.d= e/ =E2=98=8E +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 8. Mai 1945: Wer nicht feiert hat den Krieg verloren. 8 de mayo de 1945: Quien no festeja perdi=C3=B3 la Guerra. May 8, 1945: Who does not celebrate lost the War. --J/dobhs11T7y2rNN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlljDw0ACgkQR8z35Hb+ nRFEPRAAnabnd70ILlE5iNoPShbzcj61aAnpBHu4Dy2HOYzZAsNIoEQ+wv0Qjmoc 3wxqqyjIoTDY6pgzxVHOK6/PMrAdA7OaYOJWfu/QtXo0aqX4qsHyf2TK8zbwGWzs q1ingtBg7BwBZ7CHPgPf4CiuQTyle6RU64icNOtRMCUAZMuSK4sOBiqU7CCCKuYZ CWes7YRBSPMZ0aojaxoS815L+8C+2M7t5Y3MUJ6Gz5pwKEEYT6L4eAp/ylpJMBz9 MkHosNRF81ZcZk+cYyFRCSIEew4/yxSAMkXeYbFH7YPivqosc/RTOIGPtZDnhS3P ErqHNpy3kXyw7UNMzSeuYZMjIg2N2XrodgIK5yqHQIvzcuNCKDGjSNrdVprcf5FD 32Ieqt2I+TuZwdNwCe1sGIoNoWLvHD4Le5Nw/h+z8Uy7clbEF7y/nxtamks256HB tZwiAZBVUbTGw7riVT7hrNPpkvoyIlaHPJSGTdLA/182lntCG5ZKWXDTq/HLR/CI yV4VwjTIGGJct2GYUC8cZkn1zTeyILGWlTAfqSgAZMgjHvDBxeZVTig8el6mD0zy 4eSBcRqPbiq4656MQTPfJreQ1sqPztOF2jVJbA1DLbQT/mowyJOMjwGViJQB54tv OHsyilkWH/6W7ChGMlzklArQfzGvga3y4BceKuNftgEBXf3XrCk= =J113 -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170710052228.GA2338>