> Having thought this over some more, if a
> shred/scramble/scrub command is created in its own
> right, then a number of new features could be added
> that do not currently exist.

> - The command could be writen to protect a single
> file, or, it could also write to an entire file
> system/media.

These won't share much beyond what patterns to write
and how many times.

> - The command could offer many types of randomising
> possiblities, eg the current 0xff, 0x00, 0xff; or
> perhaps /dev/random could be written; or perhaps the
> user could specify exactly what is to be used to
> overwrite the file/file system - from memory some
> large organistations (govt depts) have specific rules
> about how files/file systems should be overwritten
> before old medie is thrown out and replaced (so no-one
> can scavenge the media and read sensitive data)

IMHO even this does not address paranoia very well. The
point of rm -P is to make sure freed blocks on the disk don't
have any useful information. But if the bad guy can read the
disk *while* it also holds other files on it, the battle is
already lost as presumably he can also read data in live
files. If you are using rm -P in preparation to throwing a
disk away, you may as well just use a whole disk scrubber.
If you are using rm -P to prevent a nosy admin to look at
your sensitive data, you will likely lose. He can easily
replace rm with his own command. A separate scrub command
may help since you can verify the data is erased.

This is not to say rm -P or scrub is not helpful. If you
know what you are doing it is perfectly adequate. But if you
don't or you make mistakes, it will give you a false sense of
security. For example, once a file is unlinked through some
other means (such as mv) you don't have a handle on it any
more to scrub. Basically you lost the ability to scrub your
data due to a mistake. Worse, editing such a file may free
unscrubbed blocks. A separate command won't help.

This is why I suggested to have the system do this for you
(through a mount option -- I don't care enough to want to
implement it).

> Kind of thinking out loud here, apologies if its
> noisy, Tim.

If the end result is clear headed go right ahead!
freebsd-hackers@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"