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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS 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 11E97C43381 for ; Wed, 13 Mar 2019 19:22:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C87862075C for ; Wed, 13 Mar 2019 19:22:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=hansenpartnership.com header.i=@hansenpartnership.com header.b="MMAUL5b1" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728891AbfCMTWD (ORCPT ); Wed, 13 Mar 2019 15:22:03 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:40092 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728274AbfCMTRz (ORCPT ); Wed, 13 Mar 2019 15:17:55 -0400 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 384F38EE20E; Wed, 13 Mar 2019 12:17:54 -0700 (PDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZt-0s5b79oz; Wed, 13 Mar 2019 12:17:53 -0700 (PDT) Received: from [153.66.254.194] (unknown [50.35.68.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 7EAF38EE0D2; Wed, 13 Mar 2019 12:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1552504673; bh=Fu0rh0TRSo8BaUrCb49LTC7bQJGPtb3oRoEl3FHPnWQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=MMAUL5b13FHBelUi0weo/FqU+w76a/8A7uGTeOgVAIufwe4TjYgw6TCJ8YcNFS3mT MhPGWvI1phUSuCGudujMFwOUbXacW7dPUkwV4il9jQtbv5seYWCjq7gf88xj78kvHc d2vZLA0GzhrsqDC9W4YNuTO5JjmwF8OSimLcHA3k= Message-ID: <1552504672.3022.59.camel@HansenPartnership.com> Subject: Re: overlayfs vs. fscrypt From: James Bottomley To: Theodore Ts'o Cc: Amir Goldstein , Richard Weinberger , Miklos Szeredi , linux-fsdevel , linux-fscrypt@vger.kernel.org, overlayfs , linux-kernel , Paul Lawrence Date: Wed, 13 Mar 2019 12:17:52 -0700 In-Reply-To: <20190313185826.GA4685@mit.edu> References: <4603533.ZIfxmiEf7K@blindfold> <1854703.ve7plDhYWt@blindfold> <4066872.KGdO14EQMx@blindfold> <20190313151633.GA672@mit.edu> <1552491394.3022.8.camel@HansenPartnership.com> <20190313164439.GF672@mit.edu> <1552499104.3022.44.camel@HansenPartnership.com> <20190313185826.GA4685@mit.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2019-03-13 at 14:58 -0400, Theodore Ts'o wrote: > On Wed, Mar 13, 2019 at 10:45:04AM -0700, James Bottomley wrote: > > > If they can't break root, then the OS's user-id based access > > > control checks (or SELinux checks if you are using SELinux) will > > > still protect you. > > > > Well, that's what one would think about the recent runc exploit as > > well. The thing I was looking to do was reduce the chances that > > unencrypted data would be lying around to be discovered. I suppose > > the potentially biggest problem is leaking the image after it's > > decrypted by admin means like a badly configured backup, but > > unencryped data is potentially discoverable by breakouts as well. > > But while the container is running, the key is available and > instantiated in the kernel, and the kernel is free to decrypt any > encrypted file/block. In the current encrypted tar file implementation, while the container is running the decrypted tar file is extracted into the container root and available for all to see. The main security benefit of this implementation, as I said, is security of at rest images and the runtime security is guaranteed by other systems. > The reason why the kernel won't do this is because of its access > control checks. > > And we're talking about this within the context of the overlayfs. > When in the container world will we have persistent data that lasts > beyond the lifetime of the running container that will be using > overlayfs? I didn't think that existed; if you are using, say, a > Docker storage volume, does overlayfs ever get into the act? And if > so, how, and what are the desired security properties? Are you asking about persistent volumes? I can answer, but that's not the current use case. The current use case is encrypted images, which are overlays. If you mean the misconfigured backup comment then I was thinking a backup that wrongly sweeps container root while the container is running. Lets go back to basics: can fscrypt provide equivalent or better protection than the current encrypted tarfile approach? If the answer is no because it's too tightly tied to the android use case then perhaps there's not much point discussing it further. James