svn commit: r214596 - head/bin/rm

[David Schultz]

On Sun, Oct 31, 2010, Pawel Jakub Dawidek wrote:
> On Sun, Oct 31, 2010 at 08:11:19PM +0100, Ulrich Spoerlein wrote:
> > On Sun, 31.10.2010 at 17:06:03 +0100, Pawel Jakub Dawidek wrote:
> > > IMHO this option should be removed and rm(1) should fail when a user is
> > > trying to use it.
> > 
> > No, this is a POLA violation for no apparent gain. The flag has been in
> > FreeBSD since at least '94. Remember, that we are in the rope-selling
> > business. We empower the users to shoot themselves in the foot.
> > 
> > I, for one, am using the -P option in a certain case where I can be sure
> > that ~99% of the data will be obliterated and I'm fine with that. For
> > all other cases I'm using geli or gbde (where I can make sure, that data
> > is lost).
> 
> The question remains unanswered: If it is not a security feature then
> what's the purpose?
> 
> IMHO this is a security feature, just a really lame one. Too many
> requirements have to be meet to make it work. 
> 
> I don't think you would want to read in GELI or GBDE manual page that it
> encrypts the data sometimes, or if all the given requirements are meet.
> Of course requirements are fine, but they have to be really clear to the
> user and the list should be as short as possible, which is not the case
> here.

(apologies for the late reply)

You guys are thinking mainly about physical attacks. The -P option
provides effective protection against online attacks wherein an
attacker has stashed a hard link to your sensitive file somewhere.
It's also fair to say that rm -P makes a best-effort attempt to
defend against simple commercial forensics tools, and it's about
the best you can do if you didn't think to store your data
encrypted in the first place.

Anyway, I think the current list of caveats adequately warns about
the limitations.  The one thing I would add to the manpage is a
reference to geli, recommending disk encryption to people who need
stronger protection against offline attacks.