From owner-freebsd-security Thu Jun 24 22:26:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from users.anet-stl.com (users.anet-stl.com [209.145.150.20]) by hub.freebsd.org (Postfix) with ESMTP id 7233B150EE for ; Thu, 24 Jun 1999 22:26:22 -0700 (PDT) (envelope-from doogie@anet-stl.com) Received: from earth.anet-stl.com (doogie@earth.anet-stl.com [209.83.128.12]) by users.anet-stl.com (8.9.3/8.8.5) with SMTP id FAA23190; Fri, 25 Jun 1999 05:26:16 GMT Date: Fri, 25 Jun 1999 00:26:16 -0500 (CDT) From: Jason Young To: cjclark@home.com Cc: freebsd-security@FreeBSD.ORG Subject: Re: Secure Deletion In-Reply-To: <199906250212.WAA07810@cc942873-a.ewndsr1.nj.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 24 Jun 1999, Crist J. Clark wrote: > 1) Is there a way for me to securely destroy the file that still > exists? For example, if I were to do something like (this is just > an example), > > # BADLEN=`ls -l | awk '{ print $5 }'` > # dd if=/dev/zero of= bs=1 count=$BADLEN > # dd if=/dev/urandom of= bs=1 count=$BADLEN > # dd if=/dev/zero of= bs=1 count=$BADLEN > > Would I know for sure that the writes physically went over the bad > data? If they do, a procedure like that should be fine. I think that would stop pretty much anyone except the NSA. > 2) Now... for the files that /had/ the data, but deleted it... My > suspicions here lean towards the worst case, i.e. there could be > fragments of the offensive data _anywhere_ on the partition[0]. Is > there a feasible way to destroy that data while preserving the > other data on the partition? If not, what would be the equivalent > of the above for a full partition? > > # umount /dev/wd1f > # dd if=/dev/zero of=/dev/rwd1f count= > # dd if=/dev/urandom of=/dev/rwd1f count= > # dd if=/dev/zero of=/dev/rwd1f count= > # newfs /dev/rwd1f > > Thanks for any help on this. Create a file that consumes all unused space on the partition. Do it as root so you get the "reserve" area too. Blat data over it as you would the existing file above. Then rm it. Must be something terribly important in that (former) file... Jason Young ANET/accessUS Chief Network Engineer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message