Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp768720pxy; Thu, 22 Apr 2021 13:00:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx2P987TlMOpyBu9BlVHX1gKsbQ+jaMIVoqtqNfNA/2JtInzGr4G2+Uagp6Gv6rAMOyIOmz X-Received: by 2002:a17:906:b890:: with SMTP id hb16mr360275ejb.221.1619121610587; Thu, 22 Apr 2021 13:00:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619121610; cv=none; d=google.com; s=arc-20160816; b=opWUmFERPMq4jMs/LLkH2ZQASWMJwhpWKjXre+r10HEuPMURe8L854mMltWSq/U0Qu U0M2znisPbuXbHjOm9wYAOtXiQGLNBaxNt75RsTRGe4/H1M0vaB6RhairFFyZKF36Jcp mgW/aLqC0wc3I27vzzhnndfvNcTER1krw9ZCd20HWdNwTPEl+teoAvGuUJ1RD6GQBfzX McjXk04e39grVC/pFRS4Sl7QyDhVLH+ACgMFcIMP4ZkMFeMi3LnilDIEPjAWAFAjByHc mL/eo6DrqqE3SJvCx5bjLmhOVcJ0LaoAgV1oo4xS3SQ76zK5DFSCzBJJKbmnxv09Ngg1 uWYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=aRAc16KEsyVC+w1aP+1m+8BNZmlxVG8mKMdupJ9k4y4=; b=dcpVjp81bQfxL39PhkptFqsB9m8NjGyWt+UbTXsroEPZ+4ghTJrNTqdfrgyRosAiol PMp7fiE4FbkQtgqm64jbpPFheF0r0acCg5MQxgOqds+CwAq/uvIt90ZOGVod+yvPddmD v4X/jJw/E35Q+ATS+54cglU/39lWNi4YRyUtrexd+fs4Z0VWfqhgg+mG2ZVV4IgvBgy+ 8tVLIp5kDpVCfDWPKfed6yFliTN/IpLH5v16bqQqpJ4wYN0/v1LfAB2cvLodGuY8cUgb KCXPprAfVWzDcNFyw5uaAp9Amo6dipAYXHbzqlm8jWiLpdwxVjaO4uiA7WXxZejGJ5Bm XkFA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t16si3749095edi.299.2021.04.22.12.59.38; Thu, 22 Apr 2021 13:00:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236947AbhDVT7C (ORCPT + 99 others); Thu, 22 Apr 2021 15:59:02 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:40232 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S236058AbhDVT7B (ORCPT ); Thu, 22 Apr 2021 15:59:01 -0400 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 13MJwJbJ014299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Apr 2021 15:58:20 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id A2CFA15C3B0D; Thu, 22 Apr 2021 15:58:19 -0400 (EDT) Date: Thu, 22 Apr 2021 15:58:19 -0400 From: "Theodore Ts'o" To: Andreas Dilger Cc: Eric Biggers , Leah Rumancik , linux-ext4@vger.kernel.org Subject: Re: [PATCH v3] ext4: wipe filename upon file deletion Message-ID: References: <20210419162100.1284475-1-leah.rumancik@gmail.com> <3D2D6626-DF0A-4476-AD2D-8E43477A6176@dilger.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3D2D6626-DF0A-4476-AD2D-8E43477A6176@dilger.ca> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu, Apr 22, 2021 at 11:44:49AM -0600, Andreas Dilger wrote: > Since the "delete-after-the-fact" method of security is always going > to have holes in terms of recovering data from the journal, from the > flash device, etc. why not use fscrypt for this kind of workload, if > the data actually needs to be secure? Wiping the journal is something that will be coming soon --- prototype versions of that patch have been sent out, and the main controversy has been whether it should be an ext4-specific interface, or whether it should be done in a file system independent API, and if so, how to define it. Whether or not you can recover it from the block device is very block device specific. There are certainly situations, such as people running VM's on AWS, Azure, GCP, etc., where they don't have physical access to the block device, where making sure it can be wiped so it can't be accessed via software is quite sufficient. Even if you have physical access to block device, recovering overwritten information from a HDD is *not* trivial. Not all adversaries have access to scanning electronic microscopes, and demonstrations that overwritten disk sectors were done decades ago, when the magnetic domains were far larger. Using fscrypt is certainly an option, but using encryption is not free from a performance standpoint, and you still have to answer the question of where the encryption keys would be stored. Cheers, - Ted P.S. Interesting info from https://security.stackexchange.com/questions/26132/is-data-remanence-a-myth: The best citation I can give is from Overwriting Hard Drive Data: The Great Wiping Controversy, which was published as part of the 4th International Conference on Information Systems Security, ICISS 2008. You can view the full text of the paper by viewing the book on Google Books, and jumping to page 243. The following excerpt is from their conclusion: The purpose of this paper was a categorical settlement to the controversy surrounding the misconceptions involving the belief that data can be recovered following a wipe procedure. This study has demonstrated that correctly wiped data cannot reasonably retrieved even if it of a small size or found only over small parts of the hard drive. Not even with the use of a MFM or other known methods. The belief that a tool can be developed to retrieve gigabytes or terabytes of data of information from a wiped drive is in error. Although there is a good chance of recovery for any individual bit from a drive, the chance of recovery of any amount of data from a drive using an electron microscope are negligible. Even speculating on the possible recovery of an old drive, there is no likelihood that any data would be recoverable from the drive. The forensic recovery of data using electron microscopy is infeasible. This was true both on old drives and has become more difficult over tine. Further, there is a need for the data to have been written and then wiped on a raw unused drive for there to be any hopy of any level of recovery even at the bit level, which does not reflect real situations. It is unlikely that a recovered drive will have not been used for a period of time and the interaction of defragmentation, file copies and general use that overwrites data areas negates any chance of data recovery. The fallacy that data can be forensically recovered using an electron microscope or related means needs to be put to rest. NIST also seem to agree. In NIST SP 800-88, they state the following: Studies have shown that most of today’s media can be effectively cleared by one overwrite. Purging information is a media sanitization process that protects the confidentiality of information against a laboratory attack. For some media, clearing media would not suffice for purging. However, for ATA disk drives manufactured after 2001 (over 15 GB) the terms clearing and purging have converged.