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
next prev parent 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