From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v1.tansi.org (mail.tansi.org [84.19.178.47]) by mail.server123.net (Postfix) with ESMTP for ; Fri, 16 Jun 2017 16:31:37 +0200 (CEST) Received: from gatewagner.dyndns.org (77-56-144-126.dclient.hispeed.ch [77.56.144.126]) by v1.tansi.org (Postfix) with ESMTPA id 63D71140152 for ; Fri, 16 Jun 2017 16:31:21 +0200 (CEST) Date: Fri, 16 Jun 2017 16:31:36 +0200 From: Arno Wagner Message-ID: <20170616143136.GA6852@tansi.org> References: <20170614234040.4326-1-mhalcrow@google.com> <0b268ff7-5fc8-c85f-a530-82e9844f0400@gmail.com> <20170615172450.GA27384@google.com> <20170616125511.GA11824@yeono.kjorling.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20170616125511.GA11824@yeono.kjorling.se> Subject: Re: [dm-crypt] [RFC PATCH 0/4] Allow file systems to selectively bypass dm-crypt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Fri, Jun 16, 2017 at 14:55:11 CEST, Michael Kj=F6rling wrote: > On 15 Jun 2017 10:24 -0700, from mhalcrow@google.com (Michael Halcrow): > >> 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. > >=20 > > 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. >=20 > No; it would seem to expand the attack surface to _anything_ that can > set this flag on write. That implies that at the very least _anything_ > that runs as root can now plant _plain text_ on storage media which is > intended to be fully encrypted.=20 On the surfacte, root can do that anyways. But this would allow to do that without a kernel compromise or direct write to disk. And it would make detection of a related attack much harder, hence violating KISS rather badly. [...] > If double encryption is too expensive, particularly in the product > space where one device is typically controlled by a single individual > or entity, why do file system layer encryption at all? Just offload > that to the device layer; in this case, LUKS and dm-crypt. File system > layer encryption makes more sense where a large number of users all > have deep level access to a system, possibly being able to read disks > directly, and want to keep data secure from other users of the same > system. I fail to see how that threat model is particularly relevant > in the mobile space. Same here. And I do not see why there would be significant=20 performance or energy impact either. AES hardware is fast=20 and does not consume a lot of energy.=20 Regards, Arno --=20 Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of=20 "news" is "something that hardly ever happens." -- Bruce Schneier