Date: Mon, 10 Jul 2017 10:26:25 -0500 (CDT) From: "Valeri Galtsev" <galtsev@kicp.uchicago.edu> To: "Steve O'Hara-Smith" <steve@sohara.org> Cc: freebsd-questions@freebsd.org Subject: Re: Unusual Question Message-ID: <26749.128.135.52.6.1499700385.squirrel@cosmo.uchicago.edu> In-Reply-To: <20170710090547.15ee3afc07c09955ba621ae1@sohara.org> 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> <20170710090547.15ee3afc07c09955ba621ae1@sohara.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, July 10, 2017 3:05 am, Steve O'Hara-Smith wrote: > On Mon, 10 Jul 2017 07:22:28 +0200 > Matthias Apitz <guru@unixarea.de> wrote: > >> 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 > > I see no reason why it shouldn't, provided the dd process doing the > work never needs to swap anything in (likely it's small and running a > tight loop). > >> 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 > > The sectors are still there, just filled with 0s or random data the > kernel will have no trouble reading them. I believe, the kernel addresses swap not by addressing sectors on raw device covering the whole physical drive, but as "relative sectors" through swap partition device. If I'm right, once drive partition table is gone reading swap will fail and panic kernel. And even though dd has small footprint there maybe some process whose stuff was swapped out; and the kernel does keep switching between processes. Of course, clever person will kill everything. But the suggestion you made in another post: to make tiny bootable system with dd, boot off it, and then overwrite everything else is probably the only way to go in this remote situation. Which became obvious to all of us after someone - YOU - suggested it. THANKS! Valeri > >> kernel will just crash or halt and you will notice that as terminating > > The kernel will not crash or halt, processes will if they have to > page in corrupted data but that's all. Processes that don't page in > anything will just carry on running - if they don't read the disc they'll > never know it's been overwritten. > >> ssh session. > > Unless sshd has to page something in it won't crash. > >> Do not rely on the fact that the (sensitive) information on >> the disk was overwritten. > > I see no reason to expect that the dd process won't finish clearing > the disk and exit normally. > >> 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. > > Sure, but absent a motive to spend the money forensic data analysis > costs writing 0s or random numbers over the whole drive will do fine. If > you fear forensic analysis then use thermite. > > -- > Steve O'Hara-Smith <steve@sohara.org> > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org" > ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?26749.128.135.52.6.1499700385.squirrel>