lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20170620144423.GA22495@redhat.com> Date: Tue, 20 Jun 2017 10:44:23 -0400 From: Mike Snitzer <snitzer@...hat.com> To: Michael Halcrow <mhalcrow@...gle.com> Cc: Milan Broz <gmazyland@...il.com>, "Theodore Y . Ts'o" <tytso@....edu>, Eric Biggers <ebiggers@...gle.com>, dm-crypt <dm-crypt@...ut.de>, dm-devel@...hat.com, linux-block@...r.kernel.org, Tyler Hicks <tyler.hicks@...onical.com>, linux-fscrypt@...r.kernel.org, "Daniel P. Berrange" <berrange@...hat.com>, linux-fsdevel@...r.kernel.org, Jaegeuk Kim <jaegeuk@...nel.org>, linux-ext4@...r.kernel.org Subject: Re: [RFC PATCH 0/4] Allow file systems to selectively bypass dm-crypt On Fri, Jun 16 2017 at 2:42pm -0400, Michael Halcrow <mhalcrow@...gle.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.
Powered by blists - more mailing lists