"secure" file flag?

[Terry Lambert]

Wes Peters wrote:
> On Tuesday 18 November 2003 16:31, Rayson Ho wrote:
> > e.g. when deleting a "secure" file, the OS will overwrite the file
> > with random data.
> 
> Better to overwrite it with a more "secure" pattern.  See ports/
> sysutils/obliterate for references.  It has been mentioned before that
> this could be done on in the kernel, obliterating blocks in the VM
> rather than zeroing them.  I hadn't thought of applying at the file or
> filesystem level.

The DOD has a specific pattern it requirs, to consider the deletion
to be secure.


> The closest we have is the 'rm -P' command and the above-mentioned
> obliterate command.  The overwrite pattern used in 'rm -P' is not
> likely to be effective against a dedicated inspection of the disk; the
> one in obliterate somewhat more so.

On most modern drives, nothing is likly to be ffective, without OS
support all th way down to the driver and hardware flags level.

The DOD specified pattern is only effective if you have separate
control of the seek and the write.  The reason for this is that you
musttake head hysteresis into account since if you did a seek in
for the initial write and a seek out for the erase, you will ens up
with a small strip of bits that are readable, even if they are much
smaller than a standard track width, since there is jitter in the
head positioning that depends on the side of the track you are coming
from.

So in reality, you also need to control sector sparing and write
caching, as well, to avoid track caching, if possible, and seeks for
sector sparing which are hidden from the OS trying to invoke the
write pattern: you need to turn both of these off, if you can.  If
you can't, you need to buy a different disk, and turn both of these
off, if you can.  If you can't, you are going to ned to write your
own disk firmware.

You also need to deal with not writing to tracks at one end or the
other of the disk, since you can't seek to them from the opposite
direction, which means you have no way to write the pattern you are
expected to write.  This generally means that the end tracks need
to be treated as "scrath landing zones", and you only ever write
pattern data to them, and then only because that's the way to get
the disk head onto the track so you can seek back to the track that
you really want to erase.

In a track-caching world, this tends to be not useful, unless you
can determine the physical geometry of the disk, and treat tracks as
separate entities.

Finally, if you have a track-caching disk, it's likely that the way
it operates is to just seek in and start writing.  That will mean
that in order to avoid a thin stripe of your old bits, you have to
trat tracks as singl entities, and that means that if you have a
track that shares data with several files, and you want to scribble
over one of them effectively, you have to scribble over everything
effectively, and then put the data for the filec(s) you didn't want
to erase back on the track.


> This sounds like an interesting file flag.  Would you expect the process
> to block on the unlink(2) call while the overwrite takes place, or for
> this to happen in a kernel thread?  The former seems pretty straight-
> forward, hacking at ffs_blkfree.  The latter I really wouldn't know how
> to begin without (a lot) more study.

You would have to do the former, or you would not pass common criteria
valuation, if that's what you are aiming for.

The normal way this is handled in government secure facilities is a 2U
rack unit containing thermite charges.

The normal way this is handled in a commercial scure facility is mostly
to put the disks in a crusher.

If this is somthing other than that, I doubt anyone would be willing
to spend US$60,000/MB to have someone recover your porn.  You are
likely safe enough with PHK's somewhat inscure disk encryption thingy.


As an overall note, you might want to contact Michal Serrachio off
list; he has a solution to this problem which h might be willing to
license to you for a fee.

-- Terry