On Fri, Jun 16 2017 at 2:42pm -0400, Michael Halcrow <mhalcrow@xxxxxxxxxx> 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.
