From owner-svn-src-all@FreeBSD.ORG Fri Dec 3 21:59:15 2010 Return-Path: Delivered-To: svn-src-all@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44BE3106566C; Fri, 3 Dec 2010 21:59:15 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 97E748FC12; Fri, 3 Dec 2010 21:59:14 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.4/8.14.2) with ESMTP id oB3LxDJp038506; Fri, 3 Dec 2010 16:59:13 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.4/8.14.2/Submit) id oB3LxDRi038505; Fri, 3 Dec 2010 16:59:13 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Fri, 3 Dec 2010 16:59:13 -0500 From: David Schultz To: Pawel Jakub Dawidek Message-ID: <20101203215913.GA38186@zim.MIT.EDU> Mail-Followup-To: Pawel Jakub Dawidek , Ulrich Spoerlein , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201010310921.o9V9LSo4075408@svn.freebsd.org> <20101031160603.GD2160@garage.freebsd.pl> <20101031191119.GM46314@acme.spoerlein.net> <20101031195003.GE2160@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101031195003.GE2160@garage.freebsd.pl> Cc: svn-src-head@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, src-committers@FreeBSD.ORG, Ulrich Spoerlein Subject: Re: svn commit: r214596 - head/bin/rm X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 21:59:15 -0000 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.