"secure" file flag?

[Wes Peters]

On Sunday 23 November 2003 04:46 am, Stefan Eßer wrote:
> On 2003-11-23 00:19 -0800, Wes Peters <wes at softweyr.com> wrote:
> > On Saturday 22 November 2003 02:54 am, Stefan Eßer wrote:
> > > On 2003-11-22 11:04 +0100, Dag-Erling Smørgrav <des at des.no> wrote:
> > > > Stefan Eßer <se at 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 
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? 
> > 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 
going to run tools that would potentially eliminate that data from the 
disk.  I'm designing to the idea of a disk that has been physically taken 
to a data recovery lab, because the intermediate steps don't interest me.  
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 
disk in a partly erased state is the same as leaving it unerased.  If you 
don't want the processing delay needed to do the full erasure you 
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 
understanding of the expense and abadoned it for that reason.  I may 
someday do it in the simplest form just to prove it workable to myself, 
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% 
the computational cost.  I basic infrastructure that provides a "secure 
removal" flag at the file and/or filesystem layer and a choice of 
patterns would be a nice solution.  Those who just want to make sure the 
contents of an email aren't inadvertantly disclosed to another user could 
specify a simple pattern like overwrite with zeros once, those who want 
to keep the FBI at bay could use the whole 37 passes and spend days 
deleting files.  Maybe I'll look into this again after all.  The former 
variant seems like it might even be useful for a mail server or similar 
application.

Have you seen any literature on secure overwrite patterns for flash?  That 
would be an interesting option to provide.  If nothing else, I'd like to 
hack something like that into obliterate.

-- 

        Where am I, and what am I doing in this handbasket?

Wes Peters                                               wes at softweyr.com