Groups | Search | Server Info | Keyboard shortcuts | Login | Register

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

Re: shred or scrub

Show all headers | View raw

crankypuss <crankypuss@nomail.invalid> writes:
> On 04/24/2014 02:46 PM, David Brown wrote:

[...]

>> My point is that it is impossible for a /filesystem/ to guarantee
>> erasure of old data.
>
> If you're talking specific linux filesystems, or linux filesystems in
> general, that may be the case; if you're talking filesystems in the
> wholly general sense, it is not the case.
>
>> In many cases, you could get very close - on a harddisk, if you
>> overwrite an existing sector then old data on the sector is gone for
>> ever (the idea of having to make multiple passes of random data, ones,
>> zeros, etc., is a baseless myth).
>
> Assuming that you verify that the data has actually been overwritten,
> yes; however, read/verify-after-write is costly, so it becomes a
> performance-vs-reliability issue unless there are specific interfaces
> to specify the various operations.

[...]

>> In other cases, particularly SSDs, then overwriting existing logical
>> sectors does not affect the old data directly, and it could be
>> recovered.  Other forms of data storage, such as cloud storage, are
>> getting more common - and you have even less control there.
>
> If there is no device reliability, the device should not be used for
> critical data.

If the device is 'a SSD', that is, a NAND flash ROM with and onboard
computer supposed to provide the illusion of an IDE/ SATA device and to
hide the deficiencies of the 'storage technology' as hard as possible
(ie, at least one hardware manufacturer's manual states that the
recommended procedure for dealing with sectors refusing to be programmed
is to keep erasing and re-programming them until write errors can't be
detected immediately anymore[*]) it shouldn't - technically - be used for
any data. These devices also usually employ so-called 'wear-leveling',
meaning they try to distribute writes evenly among all sectors so that
they all wear out at the some speed and (likely, since nobody really
knows what the onboard computer is actually doing) also relocated data
to 'still working sectors' to cope with 'not working anymore' sectors.

[*] This doesn't necessarily mean that the next read will still return
the data, especially considering that 'NAND flash reads' can destroy
the data 'spatially close other data' as a side effect.

(OTOH, they're cheap and fast (to read, the write speed is seriously
grotty but nobody wants to notice that) and only some orders of
magnitude less reliable than DRAM without error detection and/or
correction ---

> You wouldn't expect a large business to send its daily
> cash intake to the bank by using some homeless person grabbed off the
> street, and using cloud storage is similar; some may be reliable but
> others not.

--- and 'large businesses' routinely use this technology for dealing
with other people's money: ATMs/ cash machines usually contain PCs
runnig some ancient version of Windows or (reportedly) OS/2.)

>
>> So no filesystem can actually guarantee that it can erase old data - and
>> filesystems therefore normally provide no functions to erase old data.
>
> If a courier service routinely grabs homeless people off the street to
> deliver large amounts of cash, one might wisely choose not to use
> them.
>
> We still disagree about what "no" filesystem can do.  If you mean to
> limit the discussion to "existing linux filesystems" then I might have
> no choice but to concede your point; if you want to talk about what
> can be done, what is actually possible, then we will probably continue
> to disagree on this subject.

Every filesystem is at the mercy of the storage devices it is used on. 

[...]

>> That is certainly true - your data is only as safe as your key.  But the
>> usual procedure for encrypted partitions is to enter your key (or
>> passphrase) at the keyboard when mounting.
>>
>
> Yes, and once you have done so, the mounted partition is no more
> secure than a non-encrypted partition; data security has, through your
> supplying the key, been degraded from whatever level of security is
> provided by the encryption algorithm used,

It is actually worse because the key must be retained in memory which
implies that it is possible to get it out of that again, even in ways
people usually don't want to think about, cf

https://freedom-to-tinker.com/blog/felten/new-research-result-cold-boot-attacks-disk-encryption/

> to the simple "security"
> provided by the linux protection modes.  To quote you, "for the
> paranoid, less than 100% is not good enough".

It supports stopping "unauthorized personnel" from "accessing files
they're not supposed to access". That's enough 'security'. 

> I am of the opinion that the linux protection modes inherited from
> Unix are not very "adequate", and the idea of a "superuser" is
> inherently crippled "security".  The whole user/group/world concept
> along with the ability to open files for non-exclusive access is
> ridiculously antiquated and stems from the pre-1970 era when bisync
> was state-of-the-art and the concept of servers as separate asset
> owners was little more than a foggy idea in the minds of a few.

There are at least three different concepts in this paragraph:

	1. The kind of access policies which can or cannot be configured
           via 'traditional UNIX(*) access permissions'

	2. The 'privilege separation model' use to determine which
	   applications can execute which kind of system calls.

	3. Implicit mandatory file locking (I wonder how that landed in
	   here)

ad 1) 'common Linux filesystems' support access control lists, too. I've
so far (in about 20 years) encountered exactly one 'real-world problem'
which couldn't be solved without them.

ad 2) 'Linux system call execution privileges' are actually based on a
more fine-grained 'capabilities model' and a 'UNIX(*) superuser' is
emulated by assigning all capabilities to 'UID 0 processes' by
default. AFAIK, nobody uses this except "dexstop devsloppers' and even
in this case, I strongly suspect that they're rather suffering from an
"OMG! So 1970s!"(BTNHMDI!![*]) knee-jerk reaction than trying to solve real
problems.

	[*] "But That's Not How Microsoft Does It"

ad 3) BTNHMDI? Cooperating applications have the necessary facilities
for coordinating accesses to shared files in case this is
necessary. Which it isn't always.        

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