Groups > comp.os.linux.development.system > #655

Re: shred or scrub

From	crankypuss <crankypuss@nomail.invalid>
Newsgroups	comp.os.linux.development.system
Subject	Re: shred or scrub
Date	2014-04-27 05:59 -0600
Organization	A noiseless patient Spider
Message-ID	<ljirfc$9b7$1@dont-email.me> (permalink)
References	(7 earlier) <lj6p5h$m0g$1@dont-email.me> <lj89en$q2a$1@dont-email.me> <ljbt7r$5bc$1@dont-email.me> <ljdbhe$ol8$1@dont-email.me> <ljgfuq$ils$1@dont-email.me>

Show all headers | View raw

On 04/26/2014 08:30 AM, David Brown wrote:

> I think you are failing to understand that there are multiple layers
> here.

> If the media does not support erasing or overwriting, or if it makes it
> hard to do so reliably, then /no/ filesystem can help.

> The device is not lying - it is just that no one claims that harddrives
> (or other media) work the way you apparently think they do.  Once you
> realise that your idea of harddisks as a simple array of directly
> addressable sectors is oversimplifying, and completely wrong for flash
> devices, then you will understand the issues here.

> Nonsense.  You are imagining rules about what /you/ think device
> manufacturers should do - but they are your rules, and neither device
> manufacturers nor other users play by those rules.  There are no hard
> and fast dividing lines here.

> Reliability has no remote connection with your desire for 100% erasability.

> See earlier in this post for the critical issue of what a filesystem
> actually /is/, and how it is independent of the media.
>
> A combination of filesystem and media may give you close to the 100%
> data erasability that you are looking for, although it still assumes
> there are no failures in hardware and software along the way.  Old hard
> disks did not have relocatable sectors, and thus no risk of storing data
> in places that were not addressable by the filesystem - such disks could
> be used with a filesystem that supports scrubbing.

It seems to me that we are talking at cross-purposes here; we are 
largely stating the same meanings but expressing them in different ways, 
and the syntax of our expressions is making their semantics seem more 
different than it is.

You seem to think I'm saying that hardware makers should conform to my 
views of how hardware should work, but what I'm saying is something 
different, I'm saying that the software on the client system needs to 
ascertain the nature of the subsystem that serves it files and behave 
accordingly.  Maybe that will be ascertained by looking up the device 
identification presented by the device (they do sometimes fib about what 
they are when new hardware is introduced to support existing interface 
models) then finding its characteristics in some device information 
database, or it might be ascertained by monitoring the behavior of the 
device; eventually, we are likely to reach the point where only 
behavior-monitoring is useful, bestcase.

However.  One thing I am saying is that if an operating system claims to 
support file-scrubbing on a "filesystem" that does not support 
file-scrubbing, then that operating system is broken.  If it allows a 
file that needs to be placed only on a "scrub-able" filesystem to be 
placed on any other type of filesystem, it is broken.  And if it does 
not provide interfaces that allow the programmer to identify the file as 
"scrub-able" versus "plain-old-data" when it is being created, then it 
is not exactly broken, but it definitely lame.

So, disclaimers that shred/scrub are only useful on this or that kind of 
filesystem are inherently faulty; at a minimum the shred/scrub 
operations should be returning a blatant failure indication when issued 
against a file residing on an unsupported filesystem (and never having 
used them, much less read their code, I don't know if that is the case 
or not, but as I recall the OP didn't mention their failing, only the 
warning not to trust them on this or that filesystem).

Now, granted there are not a preponderance of devices available today 
that support the concept of scrubbing, but that does not mean that 
encryption as we know it today is the answer.  An interim answer, yes, I 
suppose, but not a real answer.  Passphrase-oriented protection 
mechanisms are only useful if the passphrase cannot be guessed (through 
cleverness or a brute-force attack) and if the owner of the data cannot 
be dragged away to some cellar where he is thumped-on or waterboarded or 
whatever until he gives up the passphrase.

No, at present I have nothing better to offer than the passphrase 
concept, but if someone calls you on the phone and claims to be your 
wife or a close friend, it won't take you very long to identify the 
person as a fraud; I think it is the mechanisms involved therein that 
will provide a better answer than passphrase protection.

And I think that operating systems should place more emphasis on who is 
allowed to access "files" than whether whoever it actually is has the 
proper passphrase.  I think that instead of continuing with the old 
philosophy of a "filesystem" implemented as an integral part of a 
monolithic operating system, we need to lean more toward the concept of 
device-handlers as servers, so that the increasingly complex world of 
cloud servers and suchlike does not continue to be handled as a "special 
case" but in the same was as local devices are handled.

One thing that still amazes me is the way linux handles passwords, such 
as the omnipotent 'root' password.  Some GUI screen is presented and the 
user enters the password, with nothing whatsoever to indicate that the 
password request is not bogus.  There are better ways to handle that 
kind of thing imo.  Whatever, enjoy your pancakes.

Back to comp.os.linux.development.system | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-16 18:17 -0400
  Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-17 04:19 -0600
    Re: shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-18 22:30 -0400
      Re: shred or scrub Jasen Betts <jasen@xnet.co.nz> - 2014-04-19 07:42 +0000
        Re: shred or scrub Richard Kettlewell <rjk@greenend.org.uk> - 2014-04-19 10:04 +0100
      Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-19 02:15 -0600
      Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-19 23:05 +0100
        Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-20 02:47 -0600
          Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-20 07:56 -0500
            Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-21 03:51 -0600
              Re: shred or scrub Jasen Betts <jasen@xnet.co.nz> - 2014-04-21 11:50 +0000
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-21 06:14 -0600
            Re: shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-21 18:44 -0400
          Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-21 13:24 +0100
            Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-22 04:10 -0600
              Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-22 14:39 +0100
  Re: shred or scrub Kristof Provost <kristof@codepro.be> - 2014-04-17 13:15 +0000
    Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-17 09:40 -0500
      Re: shred or scrub Kristof Provost <kristof@codepro.be> - 2014-04-18 14:40 +0000
    Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-18 02:12 -0600
      Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-18 11:49 +0200
        Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-18 09:59 -0600
          Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-21 16:14 +0200
            Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-22 04:22 -0600
              Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-23 00:06 +0200
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-23 05:50 -0600
                Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-24 22:46 +0200
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-25 03:57 -0600
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-25 19:14 +0100
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-26 04:02 -0600
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-27 21:26 +0100
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-28 03:27 -0600
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-28 12:17 +0100
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-28 13:01 +0100
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-29 02:50 -0600
                UNIX(*)/ Linux history & system design (was: shred or scrub) Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-05 21:31 +0100
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-05 16:02 -0600
                Re: UNIX(*)/ Linux history & system design David Brown <david.brown@hesbynett.no> - 2014-05-06 01:17 +0200
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-06 01:46 -0600
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-06 15:09 +0100
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-06 23:47 -0600
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-07 16:23 +0100
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-07 10:51 -0600
                Re: UNIX(*)/ Linux history & system design Jerry Peters <jerry@example.invalid> - 2014-05-07 20:25 +0000
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-08 03:50 -0600
                Re: UNIX(*)/ Linux history & system design Jerry Peters <jerry@example.invalid> - 2014-05-08 20:24 +0000
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-09 02:23 -0600
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-09 18:36 +0100
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-09 21:24 +0100
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-07 22:01 +0100
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-08 03:37 -0600
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-08 14:02 +0100
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-09 02:56 -0600
                Re: UNIX(*)/ Linux history & system design David Brown <david.brown@hesbynett.no> - 2014-05-07 00:15 +0200
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-07 00:32 -0600
                Re: UNIX(*)/ Linux history & system design Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-05-07 08:47 +0000
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-07 10:59 -0600
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-06 14:35 +0100
                Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-26 16:30 +0200
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-27 05:59 -0600
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-27 20:15 +0100
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-28 03:29 -0600
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-28 12:06 +0100
                Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-27 21:41 +0200
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-28 04:03 -0600
                Re: shred or scrub Richard Kettlewell <rjk@greenend.org.uk> - 2014-04-28 16:44 +0100
                Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-28 23:39 +0200
      Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-18 07:37 -0500
        Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-18 10:16 -0600
          Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-18 12:01 -0500
      Re: shred or scrub Kristof Provost <kristof@codepro.be> - 2014-04-18 14:42 +0000
  Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-17 16:41 +0200

csiph-web