linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Theodore Ts'o <tytso@mit.edu>,
	Amir Goldstein <amir73il@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Miklos Szeredi <miklos@szeredi.hu>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-fscrypt@vger.kernel.org,
	overlayfs <linux-unionfs@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Paul Lawrence <paullawrence@google.com>
Subject: Re: overlayfs vs. fscrypt
Date: Wed, 13 Mar 2019 15:29:43 -0700	[thread overview]
Message-ID: <1552516183.2808.14.camel@HansenPartnership.com> (raw)
In-Reply-To: <20190313221325.GE10169@gmail.com>

On Wed, 2019-03-13 at 15:13 -0700, Eric Biggers wrote:
> On Wed, Mar 13, 2019 at 02:04:29PM -0700, James Bottomley wrote:
> > On Wed, 2019-03-13 at 13:25 -0700, Eric Biggers wrote:
> > > On Wed, Mar 13, 2019 at 01:06:06PM -0700, James Bottomley wrote:
> > > > On Wed, 2019-03-13 at 12:57 -0700, Eric Biggers wrote:
> > 
> > [...]
> > > > > fscrypt would allow the data to be stored encrypted on the
> > > > > local disk, so it's protected against offline compromise of
> > > > > the disk.
> > > > 
> > > > Container images are essentially tars of the overlays.  They
> > > > only become actual filesystems when instantiated at
> > > > runtime.  The current encrypted container image is an overlay
> > > > or set of overlays which is tarred then encrypted.  So to
> > > > instantiate it is decrypted then untarred.
> > > > 
> > > > The thing I was wondering about was whether instead of a tar
> > > > encrypt we could instead produce an encrypted image from a
> > > > fscrypt filesystem.
> > > > 
> > > 
> > > Why do you care whether the container image is encrypted on the
> > > local disk, when you're extracting it in plaintext onto the local
> > > disk anyway each time it runs? Even after the runtime files are
> > > "deleted", they may still be recoverable from the disk.  Are you
> > > using shred and BLKSECDISCARD, and a non-COW filesystem?
> > > 
> > > Now, if you wanted to avoid writing the plaintext to disk
> > > entirely (and thereby use encryption to actually achieve a useful
> > > security property that can't be achieved through file
> > > permissions), fscrypt is a good solution for that.
> > 
> > OK let's start with a cloud and container 101: A container is an
> > exactly transportable IaaS environment containing an
> > application.  The format for the exact transport is the "container
> > image" I've been describing (layered tar file set deployed with
> > overlays).  These images are usually stored in cloud based
> > registries which may or may not have useful access controls.  I
> > take it the reason for image encryption to protect confidentiality
> > within the registry is obvious.
> > 
> > Because of the exact transport, the deployment may be on my laptop,
> > on my test system or in some type of public or private cloud.  In
> > all cases bar the laptop, I won't actually own the physical system
> > which ends up deploying the container.  So in exchange for security
> > guarantees from the physical system owner, I agree to turn over my
> > decryption key and possibly a cash payment.  One of these
> > guarantees is usually that they shred the key after use and that
> > they deploy a useful key escrow system like vault or keyprotect to
> > guard it even while the decryption is being done.
> 
> 
> > Another is that all traces of the container be shredded after the
> > execution is finished.
> 
> Well, sounds like that's not the case currently even with an
> encrypted container image, because the actual runtime files are not
> encrypted on disk.

Shredding means destroying all trace including in the on-disk image. 
However, one problem with the current implementation is there's a
window between container run and container stop where the unencrypted
files are in memory and on local disk.  Access or cockup in that window
can leak confidential data.

>   Encrypting the runtime files using fscrypt with an ephemeral key
> would be useful here.  IOW, randomly generate an encryption key when
> the container starts, never store it anywhere, and wipe it when the
> container stops.
> 
> Note that this is separate from the container *image* encryption.

Actually, that was my original thought: it needn't be.  If fscrypt can
usefully add runtime security, then we could have the encrypted layer
be simply an fscrypt image ... I presume without the key we can create
a tar image of an fscrypt that is encrypted and would still be visible
on untar if we did have the key?  So the encrypted layer would be a tar
of the fscrypt filesystem without the key.

> > considering is could I be protected against either cloud provider
> > cockups that might leak the image (the misconfigured backup
> > scenario I suggested) or malicious actions of other tenants.
> 
> If the container image is encrypted with a key not on the system,
> then its confidentiality is protected from anything that may happen
> on that system.
> 
> But if the container image encryption key *is* on the system, your
> container image may be leaked either accidentally or maliciously.

Well, yes, but that's like saying if you don't want to pick up a virus
from your network unplug it.  We have to look at ways of deploying the
filesystem and the key such that it's hard to exfiltrate ... which
seems to be similar to your android fscrypt use case.

James


  reply	other threads:[~2019-03-13 22:29 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-13 12:31 overlayfs vs. fscrypt Richard Weinberger
2019-03-13 12:36 ` Miklos Szeredi
2019-03-13 12:47   ` Richard Weinberger
2019-03-13 12:58     ` Miklos Szeredi
2019-03-13 13:00       ` Richard Weinberger
2019-03-13 13:24         ` Miklos Szeredi
2019-03-13 13:32           ` Richard Weinberger
2019-03-13 14:26             ` Amir Goldstein
2019-03-13 15:16               ` Theodore Ts'o
2019-03-13 15:30                 ` Richard Weinberger
2019-03-13 15:36                 ` James Bottomley
2019-03-13 15:51                   ` Eric Biggers
2019-03-13 16:13                     ` James Bottomley
2019-03-13 16:24                       ` Richard Weinberger
2019-03-13 16:44                   ` Theodore Ts'o
2019-03-13 17:45                     ` James Bottomley
2019-03-13 18:58                       ` Theodore Ts'o
2019-03-13 19:17                         ` James Bottomley
2019-03-13 19:57                           ` Eric Biggers
2019-03-13 20:06                             ` James Bottomley
2019-03-13 20:25                               ` Eric Biggers
2019-03-13 21:04                                 ` James Bottomley
2019-03-13 22:13                                   ` Eric Biggers
2019-03-13 22:29                                     ` James Bottomley [this message]
2019-03-13 22:58                                       ` Eric Biggers
2019-03-13 16:06                 ` Al Viro
2019-03-13 16:44                   ` Eric Biggers
2019-03-13 19:19                     ` Al Viro
2019-03-13 19:43                       ` Eric Biggers
2019-03-13 15:30               ` Eric Biggers
2019-03-13 20:33               ` Richard Weinberger
2019-03-13 22:26                 ` Eric Biggers
2019-03-13 22:42                   ` Richard Weinberger
2019-03-14  7:34                     ` Miklos Szeredi
2019-03-14 17:15                       ` [RFC] fscrypt_key_required mount option Richard Weinberger
2019-03-14 17:15                         ` [PATCH 1/4] fscrypt: Implement FS_CFLG_OWN_D_OPS Richard Weinberger
2019-03-14 17:15                         ` [PATCH 2/4] fscrypt: Export fscrypt_d_ops Richard Weinberger
2019-03-14 17:15                         ` [PATCH 3/4] ubifs: Simplify fscrypt_get_encryption_info() error handling Richard Weinberger
2019-03-14 17:15                         ` [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required Richard Weinberger
2019-03-14 17:49                           ` Eric Biggers
2019-03-14 20:54                             ` Richard Weinberger
2019-03-14 23:07                               ` Theodore Ts'o
2019-03-15  7:48                                 ` Richard Weinberger
2019-03-15 13:51                                   ` Theodore Ts'o
2019-03-15 13:59                                     ` Richard Weinberger
2019-03-14 23:15                           ` James Bottomley
2019-03-14 23:42                             ` Theodore Ts'o
2019-03-14 23:55                               ` James Bottomley
2019-03-13 15:01           ` overlayfs vs. fscrypt Eric Biggers
2019-03-13 16:11             ` Al Viro
2019-03-13 16:33               ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1552516183.2808.14.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=amir73il@gmail.com \
    --cc=ebiggers@kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=paullawrence@google.com \
    --cc=richard@nod.at \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).