"secure" file flag?

[StefanEßer]

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.

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.

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.

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.

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