Re: [dm-crypt] [RFC PATCH 0/4] Allow file systems to selectively bypass dm-crypt

[Mike Snitzer <snitzer@redhat.com>]

On Fri, Jun 16 2017 at  2:42pm -0400,
Michael Halcrow <mhalcrow@google.com> wrote:

> On Thu, Jun 15, 2017 at 08:17:02PM +0200, Milan Broz wrote:
> > On 06/15/2017 07:24 PM, Michael Halcrow wrote:
> > ...
> > >> If this is accepted, we basically allow attacker to trick system to
> > >> write plaintext to media just by setting this flag. This must never
> > >> ever happen with FDE - BY DESIGN.
> > > 
> > > That's an important point.  This expands the attack surface to include
> > > the file system, so if an adversary can provide a bad encryption key
> > > or policy at the file system layer or if there's a bug in the file
> > > system that an adversary can exploit, then users setting the
> > > allow_encrypt_override option on dmcrypt would be vulnerable.
> > > 
> > >> For me, ABSOLUTE NACK to this approach.
> > > 
> > > I can understand where you're coming from.  Given our challenges on
> > > mobile, do you have any suggestions for an alternative approach?
> > 
> > Well, what I really do not like here that you are solving problem
> > of missing properly designed cryptographic filesystem by hacking
> > some layers together that were not designed to it.
> 
> Agreed.  I enthusiastically withdraw this proposal.
> 
> I think I'm instead going to look into proposing something new in the
> block layer to address performance concerns with file system
> encryption and inline cryptographic engine support.

As should have been done from the start.  The emergence of ICE support
for mobile/embedded platforms should result in a properly designed
solution to enable dm-crypt to leverage them (easier said than done!).
And if only certain files need to be encrypted then dm-crypt may or may
not be configured in the stack.

> > It would better to go with some model that actually increases security.
> > 
> > For example, if your patch marks IO operation that comes from fs as
> > REQ_NOENCRYPT, could fs send some metadata information in bio of
> > owner (user, translated to key id) instead and encrypt the sector
> > with a different key?
> 
> I really like this idea.  However because users can access the dmcrypt
> device without the file system, I wouldn't want to try to do it
> without dmcrypt maintaining additional metadata about which keys
> protect which blocks.  Even then, the user directly accessing the
> dmcrypt device would be surprised when dmcrypt returns EIO because it
> doesn't have a key for the blocks at offsets 42 and 128.
> 
> At this point I do think something new at the block layer for file
> system managed encryption and inline cryptographic engine support will
> be necessary.

Yes.