freebsd-skq/bin/rm
cem e9e0688cbd 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
2018-11-10 20:26:55 +00:00
..
tests Fix unlink(1) for files starting with - 2018-09-12 19:41:16 +00:00
Makefile Fix unlink(1) for files starting with - 2018-09-12 19:41:16 +00:00
Makefile.depend DIRDEPS_BUILD: Update dependencies. 2017-10-31 00:07:04 +00:00
rm.1 rm(1): Formalize non-functional status of -P flag 2018-11-10 20:26:55 +00:00
rm.c rm(1): Formalize non-functional status of -P flag 2018-11-10 20:26:55 +00:00