From owner-freebsd-questions@freebsd.org Mon Jul 10 15:26:26 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2BD5DAAAB8 for ; Mon, 10 Jul 2017 15:26:26 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from cosmo.uchicago.edu (cosmo.uchicago.edu [128.135.20.71]) by mx1.freebsd.org (Postfix) with ESMTP id BD77068431 for ; Mon, 10 Jul 2017 15:26:26 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: by cosmo.uchicago.edu (Postfix, from userid 48) id 9C05FCB8CE7; Mon, 10 Jul 2017 10:26:25 -0500 (CDT) Received: from 128.135.52.6 (SquirrelMail authenticated user valeri) by cosmo.uchicago.edu with HTTP; Mon, 10 Jul 2017 10:26:25 -0500 (CDT) 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> <20170710052228.GA2338@c720-r314251> <20170710090547.15ee3afc07c09955ba621ae1@sohara.org> Date: Mon, 10 Jul 2017 10:26:25 -0500 (CDT) Subject: Re: Unusual Question From: "Valeri Galtsev" To: "Steve O'Hara-Smith" Cc: freebsd-questions@freebsd.org Reply-To: galtsev@kicp.uchicago.edu User-Agent: SquirrelMail/1.4.8-5.el5.centos.7 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 15:26:27 -0000 On Mon, July 10, 2017 3:05 am, Steve O'Hara-Smith wrote: > On Mon, 10 Jul 2017 07:22:28 +0200 > Matthias Apitz 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 > _______________________________________________ > 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 ++++++++++++++++++++++++++++++++++++++++