HomeFreeBSD

rm(1): Formalize non-functional status of -P flag

Description

rm(1): Formalize non-functional status of -P flag

-P was introduced in 4.4BSD-Lite2 around 1994. It overwrote file contents
with a pass of 0xff, 0x00, then 0xff, in a low effort attempt to "really
delete" files.

It has no user-visible effect; at the end of the day, the file is unlinked via
the filesystem. Furthermore, the utility of overwriting files with patterned
data is extremely limited due to caveats at every layer of the stack[0] and
therefore mostly futile. At the least, three passes is likely wasteful on
modern hardware[1]. It could also be seen as a violation of the "Unix
Philosophy" to do one thing per tiny, composable program.

Since 1994, FreeBSD has left it alone; OpenBSD replaced it with a single
pass of arc4random(3) output in 2012[2]; and NetBSD implemented partial, but
explicitly incomplete support for U.S. DoD 5220.22-M, "National Industrial
Security Program Operating Manual" in 2004[3].

NetBSD's enhanced comment above rm_overwrite makes a strong case for removing
the flag entirely:

This is an expensive way to keep people from recovering files from your
non-snapshotted FFS filesystems using fsdb(8). Really. No more.

It is impossible to actually conform to the exact procedure given in
[NISPOM] if one is overwriting a file, not an entire disk, because the
procedure requires examination and comparison of the disk's defect lists.
Any program that claims to securely erase *files* while conforming to the
standard, then, is not correct.

Furthermore, the presence of track caches, disk and controller write
caches, and so forth make it extremely difficult to ensure that data have
actually been written to the disk, particularly when one tries to repeatedly
overwrite the same sectors in quick succession. We call fsync(), but
controllers with nonvolatile cache, as well as IDE disks that just plain lie
about the stable storage of data, will defeat this.

[NISPOM] requires physical media destruction, rather than any technique of
the sort attempted here, for secret data.

As a first step towards evental removal, make it a placebo. It's not like
it was serving any security function. It is not defined in or mentioned by
POSIX.

If you are security conscious and need to erase your files, use a
woodchipper. At a minimum, the entire disk needs to be overwritten, not
just one file.

[0]: https://www.ru.nl/publish/pages/909282/draft-paper.pdf
[1]: https://commons.erau.edu/cgi/viewcontent.cgi?article=1131&context=jdfsl
[2]: https://github.com/openbsd/src/commit/7c5c57ba81b5fe8ff2d4899ff643af18c
[3]: https://github.com/NetBSD/src/commit/fdf0a7a25e59af958fca1e2159921562cd

Reviewed by: markj, Daniel O'Connor <darius AT dons.net.au> (previous version)
Differential Revision: https://reviews.freebsd.org/D17906

Details

Provenance
cemAuthored on
Reviewer
markj
Differential Revision
D17906: rm(1): Formalize non-functional status of -P flag
Parents
rS340329: build(7): clarify buildenv target can be used for non-cross builds
Branches
Unknown
Tags
Unknown