Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.fsmpi.rwth-aachen.de!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.os.linux.development.system Subject: Re: shred or scrub Supersedes: <87mwf9xoql.fsf@sable.mobileactivedefense.com> Date: Fri, 25 Apr 2014 19:14:40 +0100 Lines: 140 Message-ID: <87k3adxomn.fsf@sable.mobileactivedefense.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net IJ8ABZrm+FRkR/WhN5orWA0DTt7MiuuMhzH8A3UariZQsbE18= Cancel-Lock: sha1:UW4nH1WDt02qVLZc/9pyQYZacxQ= sha1:awhB791sphiIy+bIZc4hL7VIrr0= Cancel-Key: sha1:grLrwzCAylaGgQ0di2YVATrFYEc= sha1:dehX8LAdn6DA/dwr6cCah8+x0ig= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Xref: csiph.com comp.os.linux.development.system:652 crankypuss 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.