From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 25 17:28:32 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84ED116A4CF for ; Tue, 25 Nov 2003 17:28:32 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E33B43FE3 for ; Tue, 25 Nov 2003 17:28:30 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfn2m.dialup.mindspring.com ([165.247.220.86] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1AOoSl-0001aS-00; Tue, 25 Nov 2003 17:27:28 -0800 Message-ID: <3FC3FC0F.71CA1639@mindspring.com> Date: Tue, 25 Nov 2003 17:04:15 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Wes Peters References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311201327.29226.wes@softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a47d6774fe1b6c9ac26b33ff457d339202350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Rayson Ho Subject: Re: "secure" file flag? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2003 01:28:32 -0000 Wes Peters wrote: > On Tuesday 18 November 2003 16:31, Rayson Ho wrote: > > e.g. when deleting a "secure" file, the OS will overwrite the file > > with random data. > > Better to overwrite it with a more "secure" pattern. See ports/ > sysutils/obliterate for references. It has been mentioned before that > this could be done on in the kernel, obliterating blocks in the VM > rather than zeroing them. I hadn't thought of applying at the file or > filesystem level. The DOD has a specific pattern it requirs, to consider the deletion to be secure. > The closest we have is the 'rm -P' command and the above-mentioned > obliterate command. The overwrite pattern used in 'rm -P' is not > likely to be effective against a dedicated inspection of the disk; the > one in obliterate somewhat more so. On most modern drives, nothing is likly to be ffective, without OS support all th way down to the driver and hardware flags level. The DOD specified pattern is only effective if you have separate control of the seek and the write. The reason for this is that you musttake head hysteresis into account since if you did a seek in for the initial write and a seek out for the erase, you will ens up with a small strip of bits that are readable, even if they are much smaller than a standard track width, since there is jitter in the head positioning that depends on the side of the track you are coming from. So in reality, you also need to control sector sparing and write caching, as well, to avoid track caching, if possible, and seeks for sector sparing which are hidden from the OS trying to invoke the write pattern: you need to turn both of these off, if you can. If you can't, you need to buy a different disk, and turn both of these off, if you can. If you can't, you are going to ned to write your own disk firmware. You also need to deal with not writing to tracks at one end or the other of the disk, since you can't seek to them from the opposite direction, which means you have no way to write the pattern you are expected to write. This generally means that the end tracks need to be treated as "scrath landing zones", and you only ever write pattern data to them, and then only because that's the way to get the disk head onto the track so you can seek back to the track that you really want to erase. In a track-caching world, this tends to be not useful, unless you can determine the physical geometry of the disk, and treat tracks as separate entities. Finally, if you have a track-caching disk, it's likely that the way it operates is to just seek in and start writing. That will mean that in order to avoid a thin stripe of your old bits, you have to trat tracks as singl entities, and that means that if you have a track that shares data with several files, and you want to scribble over one of them effectively, you have to scribble over everything effectively, and then put the data for the filec(s) you didn't want to erase back on the track. > This sounds like an interesting file flag. Would you expect the process > to block on the unlink(2) call while the overwrite takes place, or for > this to happen in a kernel thread? The former seems pretty straight- > forward, hacking at ffs_blkfree. The latter I really wouldn't know how > to begin without (a lot) more study. You would have to do the former, or you would not pass common criteria valuation, if that's what you are aiming for. The normal way this is handled in government secure facilities is a 2U rack unit containing thermite charges. The normal way this is handled in a commercial scure facility is mostly to put the disks in a crusher. If this is somthing other than that, I doubt anyone would be willing to spend US$60,000/MB to have someone recover your porn. You are likely safe enough with PHK's somewhat inscure disk encryption thingy. As an overall note, you might want to contact Michal Serrachio off list; he has a solution to this problem which h might be willing to license to you for a fee. -- Terry