svn commit: r214596 - head/bin/rm

[Alexander Best]

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 at buffalo.edu
>   there, funny things are everywhere.   |
>                       - Theodor Geisel  |



-- 
a13x