From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F50EC43381 for ; Wed, 13 Mar 2019 15:24:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 167A920643 for ; Wed, 13 Mar 2019 15:24:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726534AbfCMPYS (ORCPT ); Wed, 13 Mar 2019 11:24:18 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:33873 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725868AbfCMPYS (ORCPT ); Wed, 13 Mar 2019 11:24:18 -0400 X-Greylist: delayed 449 seconds by postgrey-1.27 at vger.kernel.org; Wed, 13 Mar 2019 11:24:17 EDT Received: from callcc.thunk.org (guestnat-104-133-0-99.corp.google.com [104.133.0.99] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2DFGYIp003657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Mar 2019 11:16:34 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id BE27B42080E; Wed, 13 Mar 2019 11:16:33 -0400 (EDT) Date: Wed, 13 Mar 2019 11:16:33 -0400 From: "Theodore Ts'o" To: Amir Goldstein Cc: Richard Weinberger , Miklos Szeredi , linux-fsdevel , linux-fscrypt@vger.kernel.org, overlayfs , linux-kernel , Paul Lawrence Subject: Re: overlayfs vs. fscrypt Message-ID: <20190313151633.GA672@mit.edu> Mail-Followup-To: Theodore Ts'o , Amir Goldstein , Richard Weinberger , Miklos Szeredi , linux-fsdevel , linux-fscrypt@vger.kernel.org, overlayfs , linux-kernel , Paul Lawrence References: <4603533.ZIfxmiEf7K@blindfold> <1854703.ve7plDhYWt@blindfold> <4066872.KGdO14EQMx@blindfold> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, Mar 13, 2019 at 04:26:54PM +0200, Amir Goldstein wrote: > AFAIK, this feature was born to tailor Android's file based encryption. > https://source.android.com/security/encryption#file-based > It is meant to protect data at rest and what happens when user enters > the screen lock password IIRC, is that some service will get restarted. > IOW, there should NOT be any processes in Android accessing the > encrypted user data folders with and without the key simultaneously. > Also, like OpenWRT, in Android the key does not get removed > (until boot) AFAIK(?). Actually, the original use was for ChromeOS, but the primary assumption is that keying is per user (or profile), and that users are mutually distrustful. So when Alice logs out of the system, her keys will be invalidated and removed from the kernel. We can (and do) try to flush cache entries via "echo 3 > /proc/sys/vm/drop_caches" on logout. However, this does not guarantee that all dcache entries will be removed --- a dcache entry can be pinned due to an open file, a process's current working directory, a bind mount, etc. The other issue is negative dentries; if you try open a file in an encrypted file, the file system won't even *know* whether or not a file exists, since the directory entries are encrypted; hence, there may be some negative dentries that need to be invalidated. So a fundamental assumption with fscrypt is that keys will be added and removed, and that when this happens, dentries will need to be invalidated. This is going to surprise overlayfs, so if overlayfs is going to support fscrypt it *has* to be aware of the fact that this can happen. It's not even clear what the proper security semantics should be; *especially* if the upper and lower directories aren't similarly protected using the same fscrypt encryption key. Suppose the lower directory is encrypted, and the upper is not. Now on a copy up operation, the previously encrypted file, which might contain credit card numbers, medical records, or other things that would cause a GDPR regulator to have a freak out attack, would *poof* become decrypted. So before we talk about how to make things work from a technical perspective, we should consider what the use case happens to be, and what are the security requirements. *Why* are we trying to use the combination of overlayfs and fscrypt, and what are the security properties we are trying to provide to someone who is relying on this combination? - Ted