From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 04:46:28 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 9428616A4CE; Sun, 23 Nov 2003 04:46:28 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B96A43FA3; Sun, 23 Nov 2003 04:46:25 -0800 (PST) (envelope-from se@freebsd.org) Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng4.kundenserver.de with esmtp (Exim 3.35 #1) id 1ANtd9-0004sV-00; Sun, 23 Nov 2003 13:46:23 +0100 Received: from [80.132.236.72] (helo=Gatekeeper.FreeBSD.org) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1ANtd9-0008Bi-00; Sun, 23 Nov 2003 13:46:23 +0100 Received: from StefanEsser.FreeBSD.org (StefanEsser [10.0.0.1]) by Gatekeeper.FreeBSD.org (Postfix) with ESMTP id 537325F18; Sun, 23 Nov 2003 13:46:21 +0100 (CET) Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id 06F931F18; Sun, 23 Nov 2003 13:46:21 +0100 (CET) Date: Sun, 23 Nov 2003 13:46:20 +0100 From: Stefan =?iso-8859-1?Q?E=DFer?= To: Wes Peters Message-ID: <20031123124620.GB1133@StefanEsser.FreeBSD.org> References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <20031122105400.GA4506@StefanEsser.FreeBSD.org> <200311230019.11310.wes@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200311230019.11310.wes@softweyr.com> User-Agent: Mutt/1.5.5.1i Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:fa3fae9b6ca38d745862a668565919f6 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 12:46:28 -0000 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 ;-) >=20 > Poppycock. Encrypting the data before it hits the disk is a fine=20 > protection against somebody later recovering the data, either=20 > 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. In doubt, I'd use encyption at the disk block level to protect sensitive=20 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). >=20 > But why would somebody trying to steal your data run fsck on it? You'r= e=20 > 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=20 the inode. This is not meant as protection in case power is removed and the disk=20 is analyzed off-line since most probably no fsck will ever be run over=20 the filesystem again. 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=20 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. 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. Regards, STefan