Re: [patch] rm can have undesired side-effects
- From: Bakul Shah <bakul@xxxxxxxxxxxxx>
- Date: Tue, 31 Oct 2006 09:44:02 -0800
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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: [patch] rm can have undesired side-effects
- From: Tim Clewlow
- Re: [patch] rm can have undesired side-effects
- References:
- Re: [patch] rm can have undesired side-effects
- From: Tim Clewlow
- Re: [patch] rm can have undesired side-effects
- Prev by Date: Re: [patch] rm can have undesired side-effects
- Next by Date: Re: [patch] rm can have undesired side-effects
- Previous by thread: Re: [patch] rm can have undesired side-effects
- Next by thread: Re: [patch] rm can have undesired side-effects
- Index(es):
Relevant Pages
|
|
