From owner-freebsd-questions@freebsd.org Mon Jul 10 05:54:38 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 78742D9E6F2 for ; Mon, 10 Jul 2017 05:54:38 +0000 (UTC) (envelope-from srs0=cpwb=6n=mail.sermon-archive.info=doug@sermon-archive.info) Received: from mail.sermon-archive.info (sermon-archive.info [71.177.216.148]) by mx1.freebsd.org (Postfix) with ESMTP id 627D57CF1A for ; Mon, 10 Jul 2017 05:54:38 +0000 (UTC) (envelope-from srs0=cpwb=6n=mail.sermon-archive.info=doug@sermon-archive.info) Received: from [10.0.1.251] (mini [10.0.1.251]) by mail.sermon-archive.info (Postfix) with ESMTPSA id 3x5ZDF4xc6z2fkDV; Sun, 9 Jul 2017 22:54:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Unusual Question From: Doug Hardie In-Reply-To: <20170710054116.GA2445@c720-r314251> Date: Sun, 9 Jul 2017 22:54:37 -0700 Cc: Doug Hardie , "freebsd-questions@freebsd.org Questions" , galtsev@kicp.uchicago.edu Content-Transfer-Encoding: quoted-printable Message-Id: <242B2A7C-7E4A-4B22-AA65-AEB6E3B40340@mail.sermon-archive.info> References: <888578F8-AD68-4993-823C-152789F3C929@mail.sermon-archive.info> <52627.76.193.16.95.1499645892.squirrel@cosmo.uchicago.edu> <20170710052228.GA2338@c720-r314251> <5156E6FD-03AE-4244-B3AB-32007439AD20@mail.sermon-archive.info> <20170710054116.GA2445@c720-r314251> To: Matthias Apitz X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean 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 05:54:38 -0000 > On 9 July 2017, at 22:41, Matthias Apitz wrote: >=20 > El d=C3=ADa domingo, julio 09, 2017 a las 10:33:40p. m. -0700, Doug = Hardie escribi=C3=B3: >=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. >>=20 >> 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. >=20 > Doug, you missed my point. Your dd proc will overwrite at some point = the > swaped-out pages and/or text segments which have been memory mapped by > the kernel. The kernel will miss them and crash and so you have only > overwritten a (maybe small) part of the disk. The swap partition is the last partition on the drive. So if dd/system = failed while writing that, then my goal would be complete. There was = nothing running on the system accessing any sensitive data. The only = areas of concern was the main partition. As for the kernel itself going = down, I would expect that would not be able to hazard a reliable guess. = It could happen, but I would expect if that were the case to not be able = to get to the 60% point.