Date: Tue, 2 Nov 2010 01:40:59 +0000 From: Alexander Best <arundel@freebsd.org> To: Ken Smith <kensmith@buffalo.edu> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>, Ulrich Spoerlein <uqs@FreeBSD.org> Subject: Re: svn commit: r214596 - head/bin/rm Message-ID: <20101102014059.GA91353@freebsd.org> In-Reply-To: <1288620951.3596.32.camel@bauer.cse.buffalo.edu> References: <201010310921.o9V9LSo4075408@svn.freebsd.org> <20101031160603.GD2160@garage.freebsd.pl> <20101031191119.GM46314@acme.spoerlein.net> <1288620951.3596.32.camel@bauer.cse.buffalo.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon Nov 1 10, Ken Smith wrote: > On Sun, 2010-10-31 at 20:11 +0100, Ulrich Spoerlein wrote: > > On Sun, 31.10.2010 at 17:06:03 +0100, Pawel Jakub Dawidek wrote: > > > On Sun, Oct 31, 2010 at 09:21:28AM +0000, Ulrich Spoerlein wrote: > > > > Author: uqs > > > > Date: Sun Oct 31 09:21:27 2010 > > > > New Revision: 214596 > > > > URL: http://svn.freebsd.org/changeset/base/214596 > > > > > > > > Log: > > > > Elaborate some more on the non-security implications of using -P > > > [...] > > > > +.Pp > > > > +N.B.: The > > > > +.Fl P > > > > +flag is not considered a security feature > > > > +.Pq see Sx BUGS . > > > > > > I'm sorry for jumping so late into the subject, but if it is not a > > > security feature than what other purpose has left? > > > > > > Really guys, this option is useless. > > > > > > There is no reliable way to verify if the blocks are really overwritten. > > > Period. > > > > > > If it is not used for security, then I see no other use for it (except > > > for [1]). > > > > > > If it is used for security then we better have a way to give the user > > > the right answer to the question "is my data really gone?" and don't > > > make false assumptions or giving answers "we hope so". > > > > > > Why there is no reliable way to verify this? > > > 1. Check file system type (UFS, ZFS). > > > 2. Check file system configuration (UFS with snapshots?). > > > 3. Be sure sync(2) the file system and send BIO_FLUSH to all the media > > > involved (some cheap flash disks lie about BIO_FLUSH support). > > > 4. Check underlying media (GLABEL provider - no modification to the data). > > > 5. Check underlying media (ZVOL - data won't be overwritten, but...). > > > 6. Check ZFS vdevs (on which providers ZVOL's pool is based on). > > > 7. Check vdevs (GELI - cool, we have encryption). > > > 8. Check GELI configuration (maybe NULL encryption algorithm?). > > > 9. Check underlying media (HDD, SSD, swap-backed md(4) device? goto 3). > > > 10. Check if the sectors weren't remapped while we were overwriting. > > > > > > In other words this is soooo complicated that it would simply be too > > > hard to explain to regular user or implement in rm(1). > > > > > > 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. > > Just playing Devils' Advocate... If the removal of -P were done as > part of a new branch the POLA argument is moot if it's judged you > are a bit off on the "no apparent gain" aspect. And the rope selling > argument also only applies so far. One could argue having our installer > by default leave a machine set up so SSH was enabled, remote root logins > were allowed, and no initial password set up for root is fine because > we're in the rope-selling business and for some portion of the user > base that's just fine. I know that's extreme but that's the point, > I'm saying it's hard to figure out exactly where the line is between > activities that are ill-advised versus those that are just plain > stupid sometimes. > > So, please, given all the attention being given to the security aspects > of users properly erasing data they should erase I'd prefer we focus on > whether providing -P at all is flat out lying and base the decision > about whether it should go based on that. Lots of things we thought > were OK back in 1994 we've changed our minds about since then. > > > 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). > > This strongly backs up Pawel's argument that the existence of -P is a > lie. > > > So we can either fix -P for all cases (impossible), or at least document > > its shortcomings. Documenting them clearly is better than what we had a > > couple of days before. > > As I said above, with re@ hat on since the claim of POLA above is > slightly based on branch/release guidelines, I think removal of -P > is also still an option if it's decided -P is a lie. how about a compromise then? let's leave the -P switch in rm, but make it a no op! in addition to that add a new rm(1) entry explaining what the -P switch did and why exactly it was turned into a no op. let's be really eloborate on this issue and tell the user exactly every tiny detail that lead to the conclusion that currently the -P switch serves no purpose and thus it was turned into a no op. also a statement should be added to rm(1) that makes clear that the -P flag *will* come back to rm, once the low level work has been finished in order to decide (from userland) whether a specific disk supports overwriting blocks or not. thoughts? cheers. alex > > -- > Ken Smith > - From there to here, from here to | kensmith@buffalo.edu > there, funny things are everywhere. | > - Theodor Geisel | -- a13x
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101102014059.GA91353>