From owner-freebsd-security Thu May 20 13: 5:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from vespucci.advicom.net (vespucci.advicom.net [199.170.120.42]) by hub.freebsd.org (Postfix) with ESMTP id 886A814F0D for ; Thu, 20 May 1999 13:05:29 -0700 (PDT) (envelope-from avalon@vespucci.advicom.net) Received: from localhost (avalon@localhost) by vespucci.advicom.net (8.8.8/8.8.5) with ESMTP id PAA06556; Thu, 20 May 1999 15:05:18 -0500 (CDT) X-Envelope-Recipient: security@FreeBSD.ORG Date: Thu, 20 May 1999 15:05:18 -0500 (CDT) From: Avalon Books To: Joel Maslak Cc: security@FreeBSD.ORG Subject: Re: Secure Deletion In-Reply-To: <3.0.6.32.19990520095507.00840010@india.wind-river.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 > 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. Actually, I've done this already. At the moment, its a simple stand-alone program (I originally wrote during my DOS days, years ago), but I've been toying with the idea of adding the method in as an option for 'rm'. No need to tie up the kernel with this sort of thing. It uses a combination of randomly-generated and pattern-specific overwrites of a file (or group of files) in-place, in order to make recovery extremely difficult--even with advanced equipment (like echo-cancellation analysis systems). A standard file-deletion is issued after its done mangling the file(s) in question. It works ok, I guess, as betas go. For course, this does nothing to compensate for all the 'weirdnesses' that hard drive manufacturers implment for the sake of performance. Just the thought of trying to write all that hardware-specific code gives me heartburn. And if somebody gets physical access to a drive before anything gets erased... well... too bad... Anyway, I have the source code if anybody wants to take a peek at it. Its my personal opinion, however, that the whole idea of performing a true security erase on magnetic media is highly problematic, at best. Recovery techniques are extremely sophisticated these days, and just overwriting a file once or twice with random junk doesn't get the job done anymore... --R. Pelletier Sys Admin, House Galiagante We are a Micro$oft-free site To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message