From owner-freebsd-security Fri May 21 1:33:57 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns0.virtual-pc.com (mailgate.virtual-pc.com [194.217.102.1]) by hub.freebsd.org (Postfix) with ESMTP id 6249914D61 for ; Fri, 21 May 1999 01:33:48 -0700 (PDT) (envelope-from gc@virtual-pc.com) Received: from virtual-pc.com (v-pc.virtual-pc.com [195.11.18.2]) by ns0.virtual-pc.com (8.9.3/8.8.5) with ESMTP id JAA22600; Fri, 21 May 1999 09:39:46 +0100 (BST) Message-ID: <374519D4.403016C2@virtual-pc.com> Date: Fri, 21 May 1999 09:31:16 +0100 From: gc X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: tim@iafrica.com.na Cc: Joel Maslak , security@FreeBSD.ORG Subject: Re: Secure Deletion References: <3.0.6.32.19990520095507.00840010@india.wind-river.com> <374474D4.2263@iafrica.com.na> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tim Priebe wrote: > > Joel Maslak wrote: > > > > Let's keep standard BSD semantics here, please! > > > > As for "secure" deletion... Why doesn't someone just write a simple > > user-space program to do that. True, it wouldn't handle calls to unlink(), > > but one would think that someone could modify the library really quick > > (provided no one does a system call directly, but uses the libc interface > > instead). I think this would be much better for everyone involved. > > > > Some problems with my idea... > > > > Static-linked executables would need to be recompiled > > Library would need to be modified on "secure" systems > > > > If all you want is a way to force a file to go away from the command line, > > just rewrite rm. > Could someone enlighten me as to why the first move is not to write back an inverted copy of the data to even out the residual field before resorting to other patterns? (this assumes you are deleting a file and thus still have the data before you start). > >From my understanding of ffs, this would not be sufficiant. As a file > grows, it is possible that the data is copied from its initial location > to a new one. To not just give a false sense of security these block > fragments would have to be over written after the data is copied, or > some of the data could still be sitting on the drive after you think it > is gone. > In that case, maybe there should be a flag attached to a given file which made the OS 'securely' wipe any sectors that had been used by the file any time it moved them. gc > Tim. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message