Date: Sun, 23 Nov 2003 10:11:32 -0800 From: Wes Peters <wes@softweyr.com> To: Stefan =?iso-8859-1?q?E=DFer?= <se@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? Message-ID: <200311231011.32965.wes@softweyr.com> In-Reply-To: <20031123124620.GB1133@StefanEsser.FreeBSD.org> References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311230019.11310.wes@softweyr.com> <20031123124620.GB1133@StefanEsser.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 23 November 2003 04:46 am, Stefan E=DFer wrote:
> 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 ;-)
> >
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311231011.32965.wes>