From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 10:11:36 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 9DF4616A4CE; Sun, 23 Nov 2003 10:11:36 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 842D743F75; Sun, 23 Nov 2003 10:11:35 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 303435B69B; Sun, 23 Nov 2003 10:10:13 -0800 (PST) From: Wes Peters Organization: Softweyr To: Stefan =?iso-8859-1?q?E=DFer?= Date: Sun, 23 Nov 2003 10:11:32 -0800 User-Agent: KMail/1.5.4 References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311230019.11310.wes@softweyr.com> <20031123124620.GB1133@StefanEsser.FreeBSD.org> In-Reply-To: <20031123124620.GB1133@StefanEsser.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200311231011.32965.wes@softweyr.com> cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: Rayson Ho cc: phk@freebsd.org cc: freebsd-hackers@freebsd.org 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: Sun, 23 Nov 2003 18:11:36 -0000 On Sunday 23 November 2003 04:46 am, Stefan E=DFer wrote: > On 2003-11-23 00:19 -0800, Wes Peters wrote: > > On Saturday 22 November 2003 02:54 am, Stefan E=DFer wrote: > > > On 2003-11-22 11:04 +0100, Dag-Erling Sm=F8rgrav wrote: > > > > Stefan E=DFer writes: > > > > > I may be way off, but I do not think, that a special thread or > > > > > a cache flush after each block is required: [...] > > > > > > > > What happens if you yank the power cord? > > > > > > Worst case: The same thing that happened, if the you lost power > > > a fraction of a second earlier, just before the unlink or loss > > > of last reference to the file ... > > > > > > Nothing short of a self-destruct mechanism will do any better ;-) > > > > Poppycock. Encrypting the data before it hits the disk is a fine > > protection against somebody later recovering the data, either > > inadvertantly or nefariously. > > Aren't we again unneccessarily rude here ? > > Encrypting data and secure removal of data are orthogonal and in case > you need one, the other propbably won't be a good choice. Both are completely adequate to protect the data on the disk from=20 disclosure. > In doubt, I'd use encyption at the disk block level to protect > sensitive data, but that's not the topic of this thread, IIRC. > > The subject was to get rid of remnants of data (whether encrypted or > not) from some magnetic media (and similar methods might be suitable > for flash media with different patterns and a smaller number of > passes). > > > Back to the subject of this thread: > > > You could write a special flag "needs to be securely removed" to > > > the inode. That way, an interrupted overwrite process could be > > > continued after next reboot (for example initiated by fsck). > > > > But why would somebody trying to steal your data run fsck on it?=20 > > You're not thinking paranoid enough. > > Sorry, but what are you talking about ? > > fsck could identify incompletely erased (in the sense of multipass > overwrite with specific patterns) blocks, if that state was marked in > the inode. But if someone is attempting to recover your deleted data, they're not=20 going to run tools that would potentially eliminate that data from the=20 disk. I'm designing to the idea of a disk that has been physically taken=20 to a data recovery lab, because the intermediate steps don't interest me. = =20 But you see that: > This is not meant as protection in case power is removed and the disk > is analyzed off-line since most probably no fsck will ever be run over > the filesystem again. The data needs to be overwritten in a timely manner as well. Leaving the=20 disk in a partly erased state is the same as leaving it unerased. If you=20 don't want the processing delay needed to do the full erasure you=20 obviously don't really need full erasure. > It is meant to protect against a power failure (or reboot) with data > not being erased according to the specification, which might survive > for a long time after next start (not by an attacker but in normal > service). This is extra paranoia (compare to a crash while "obliterate" > is overwriting blocks, which will not be restarted after a crash ...) > > It seems that you are opposed to having "secure erase" support in the > kernel, and in fact, I'm not sure it is that useful, myself. No, at one time I had it on my todo list, but came to a more full=20 understanding of the expense and abadoned it for that reason. I may=20 someday do it in the simplest form just to prove it workable to myself,=20 but I doubt that is a solution of general interest to FreeBSD. > But in case it is considered useful and implemented (I'd try it myself, > if I was interested in using this feature), then we should discuss the > techical (and security) aspects of several designs and that's what I'm > trying to do. There is some merit in providing a mechanism that is 90% as secure at 10%=20 the computational cost. I basic infrastructure that provides a "secure=20 removal" flag at the file and/or filesystem layer and a choice of=20 patterns would be a nice solution. Those who just want to make sure the=20 contents of an email aren't inadvertantly disclosed to another user could=20 specify a simple pattern like overwrite with zeros once, those who want=20 to keep the FBI at bay could use the whole 37 passes and spend days=20 deleting files. Maybe I'll look into this again after all. The former=20 variant seems like it might even be useful for a mail server or similar=20 application. Have you seen any literature on secure overwrite patterns for flash? That= =20 would be an interesting option to provide. If nothing else, I'd like to=20 hack something like that into obliterate. =2D-=20 Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com