Date: Sun, 23 Nov 2003 13:46:20 +0100 From: Stefan =?iso-8859-1?Q?E=DFer?= <se@FreeBSD.org> To: Wes Peters <wes@softweyr.com> Cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? Message-ID: <20031123124620.GB1133@StefanEsser.FreeBSD.org> In-Reply-To: <200311230019.11310.wes@softweyr.com> References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <xzpzneosor3.fsf@dwp.des.no> <20031122105400.GA4506@StefanEsser.FreeBSD.org> <200311230019.11310.wes@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2003-11-23 00:19 -0800, Wes Peters <wes@softweyr.com> wrote: > On Saturday 22 November 2003 02:54 am, Stefan E=DFer wrote: > > On 2003-11-22 11:04 +0100, Dag-Erling Sm=F8rgrav <des@des.no> wrote: > > > Stefan E=DFer <se@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031123124620.GB1133>