From: Dave Chinner <david@fromorbit.com>
To: Richard Weinberger <richard@nod.at>
Cc: Michael Halcrow <mhalcrow@google.com>,
David Gstir <david@sigma-star.at>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
Theodore Ts'o <tytso@mit.edu>,
jaegeuk@kernel.org, Eric Biggers <ebiggers@google.com>,
Anand Jain <anand.jain@oracle.com>,
Tyler Hicks <tyhicks@canonical.com>
Subject: Re: [PATCH] fscrypto: make XTS tweak initialization endian-independent
Date: Thu, 6 Oct 2016 12:17:15 +1100 [thread overview]
Message-ID: <20161006011714.GT27872@dastard> (raw)
In-Reply-To: <ac10ada8-40fc-e946-7593-efa08eb875d1@nod.at>
On Wed, Oct 05, 2016 at 11:14:55PM +0200, Richard Weinberger wrote:
> Michael,
>
> On 05.10.2016 20:44, Richard Weinberger wrote:
> > Well, let's focus first on file contents.
> > We have already the fscrypo framework.
> >
> > What you suggest is completely different from what we have now.
>
> To clarify that, I'm not saying that meta-data or block level authentication
> is a bad idea. But let's start with small steps and consider file contents
> authentication first. Of course this has some attack vectors but these
> can be documented and for many use case these are acceptable.
This is the sanest approach, because encrypting filesystem internal
metadata may have some unintended consequences. e.g being unable to
perform forensic analysis of corruption or data loss events, or an
inability for tools like fsck to work without also implementing all
the encryption code in userspace and being provided with all the
keys needed to decrypt the metadata.
i.e. it's not just the kernel code we have to consider here when
discussing this level of encryption in filesystems - the impact
on the entire support ecosystem needs to be considered. A weakness
in a fsck tool will be just as serious as a weakness in the kernel
code, and there's a much larger amount of widely dispersed code that
would need to be encryption enabled by going down this path.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2016-10-06 1:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20161005170659.GA110549@google.com>
2016-10-05 18:23 ` [PATCH] fscrypto: make XTS tweak initialization endian-independent Michael Halcrow
2016-10-05 18:44 ` Richard Weinberger
2016-10-05 21:11 ` Michael Halcrow
2016-10-05 21:18 ` Richard Weinberger
2016-10-05 21:14 ` Richard Weinberger
2016-10-06 1:17 ` Dave Chinner [this message]
2016-10-06 2:16 ` Theodore Ts'o
2016-10-06 22:23 ` Dave Chinner
2016-10-07 16:05 ` Theodore Ts'o
2016-09-30 17:58 Eric Biggers
2016-10-01 16:03 ` Richard Weinberger
2016-10-03 18:03 ` Eric Biggers
2016-10-04 8:46 ` Richard Weinberger
2016-10-04 16:38 ` Eric Biggers
2016-10-05 9:08 ` David Gstir
2016-10-13 3:39 ` Theodore Ts'o
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=20161006011714.GT27872@dastard \
--to=david@fromorbit.com \
--cc=anand.jain@oracle.com \
--cc=david@sigma-star.at \
--cc=ebiggers@google.com \
--cc=jaegeuk@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mhalcrow@google.com \
--cc=richard@nod.at \
--cc=tyhicks@canonical.com \
--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).