From owner-freebsd-questions@freebsd.org Mon Jul 10 05:48:49 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 EA1A3D9E366 for ; Mon, 10 Jul 2017 05:48:49 +0000 (UTC) (envelope-from holindho@saunalahti.fi) Received: from vs23.mail.saunalahti.fi (vs23.mail.saunalahti.fi [193.64.193.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vs23.mail.saunalahti.fi", Issuer "vs23.mail.saunalahti.fi" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A9DC87CAA9 for ; Mon, 10 Jul 2017 05:48:49 +0000 (UTC) (envelope-from holindho@saunalahti.fi) Received: from vs23.mail.saunalahti.fi (localhost [127.0.0.1]) by vs23.mail.saunalahti.fi (Postfix) with ESMTP id B1E3C20091 for ; Mon, 10 Jul 2017 08:48:39 +0300 (EEST) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by vs23.mail.saunalahti.fi (Postfix) with ESMTP id A761E2006A for ; Mon, 10 Jul 2017 08:48:39 +0300 (EEST) Received: from [10.0.0.7] (62-78-248-13.bb.dnainternet.fi [62.78.248.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTPSA id 9F7BE20097 for ; Mon, 10 Jul 2017 08:48:38 +0300 (EEST) Subject: Re: Unusual Question To: freebsd-questions@freebsd.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> <5156E6FD-03AE-4244-B3AB-32007439AD20@mail.sermon-archive.info> From: Heikki Lindholm Message-ID: <947af5eb-6d29-51c2-25b8-b183561008c4@saunalahti.fi> Date: Mon, 10 Jul 2017 08:48:34 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5156E6FD-03AE-4244-B3AB-32007439AD20@mail.sermon-archive.info> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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:48:50 -0000 On 10.07.2017 08:33, Doug Hardie wrote: > >> On 9 July 2017, at 22:22, Matthias Apitz wrote: >> >> El día domingo, julio 09, 2017 a las 05:34:06p. m. -0700, Doug Hardie escribió: >> >>>>> 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. >>>>> _______________________________________________ >>> >>> 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. >> >> 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. Virtualbox would seem like the obvious choice to see what happens. Just set up a system with the same attributes and software versions and the same runtime env (daemons).