DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] [RFC PATCH 0/4] Allow file systems to selectively bypass dm-crypt
Date: Fri, 16 Jun 2017 16:31:36 +0200	[thread overview]
Message-ID: <20170616143136.GA6852@tansi.org> (raw)
In-Reply-To: <20170616125511.GA11824@yeono.kjorling.se>

On Fri, Jun 16, 2017 at 14:55:11 CEST, Michael Kjörling 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.
> > 
> > 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.
> 
> 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. 

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 
performance or energy impact either. AES hardware is fast 
and does not consume a lot of energy. 

Regards,
Arno

-- 
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 
"news" is "something that hardly ever happens." -- Bruce Schneier

  reply	other threads:[~2017-06-16 14:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170614234040.4326-1-mhalcrow@google.com>
2017-06-15  7:33 ` [dm-crypt] [RFC PATCH 0/4] Allow file systems to selectively bypass dm-crypt Milan Broz
2017-06-15 17:24   ` Michael Halcrow
2017-06-15 18:17     ` Milan Broz
2017-06-16 18:42       ` Michael Halcrow
2017-06-20 14:44         ` Mike Snitzer
2017-06-16 12:55     ` Michael Kjörling
2017-06-16 14:31       ` Arno Wagner [this message]
2017-06-16 14:47         ` Michael Kjörling
2017-06-16 18:35           ` Arno Wagner
2017-06-16 10:34   ` Daniel P. Berrange
2017-06-16 14:02   ` Arno Wagner

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=20170616143136.GA6852@tansi.org \
    --to=arno@wagner.name \
    --cc=dm-crypt@saout.de \
    /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