"secure" file flag?

[Wes Peters]

On Friday 21 November 2003 05:30, Dag-Erling Smørgrav wrote:
> Pawel Jakub Dawidek <nick at garage.freebsd.pl> writes:
> > I'm aware of this, but what we want to think over here is something
> > like in-kernel 'rm -P'. So file will be overwriten even if it is
> > opened and/or link count is grater than 0.
>
> That is not acceptable.  First of all, it breaks a lot of assumptions
> in the filesystem code.  Second, it is incompatible with the common
> technique of unlinking a temporary file immediately after opening it
> to avoid having it stick around if the process that created it dies
> prematurely.  Your proposed change would thus reduce security rather
> than enhance it.

Right.  The idea of restricting a file marked "secure" to not be able to 
link to it, and refusing to set the flag if the file has a link count 
greater than 1, is easy to do.  I'm not sure it makes sense, though.

> Besides, overwriting the contents of a file when it is removed from
> the file system is not enough.  You also need to overwrite every
> block or fragment which is released any time the file shrinks.
>
> Fortunately, ufs always truncates a file to length 0 when it is
> removed, so you only need to modify ffs_truncate() to implement both
> aspects (truncation and removal).  You should also take care to
> overwrite the file's extended attributes if it has any.

For ffs, I believe it would be as simple as providing this behavior in 
ffs_blkfree.  Both the vnode and fs are passed to ffs_blkfree, so the 
code should be able to check filesystem flags and/or file flags to 
determine if the block should be erased before freed.  This simplistic 
approach would forgo some potentially very helpful optimizations, 
though.

> Finally, I think a filesystem flag is much better for this purpose
> than a file flag; and in either case, file removal and truncation
> performance will be awful.

The filesystem flag is no more or less difficult to do; I can see doing 
both for completeness sake.

As for performance, you really need to flush the on-device cache on each 
pass to make sure the bit patterns get written to the platter in proper 
order.  I don't see any clever way to coalesce the writing of the 
various patterns to multiple blocks short of a kernel thread, either, 
so performance would be abysmal.  Imagine removing a large file, 
overwriting each block in 37 (IIRC) passes, syncing all the way through 
the on-disk cache after *every block.*

Disk encryption suddenly doesn't look so bad, does it?

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

Wes Peters                                              wes at softweyr.com