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: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-14 23:40 [RFC PATCH 0/4] Allow file systems to selectively bypass dm-crypt Michael Halcrow
2017-06-14 23:40 ` [RFC PATCH 1/4] block: Add bio req flag to disable encryption in block Michael Halcrow
2017-06-14 23:40 ` [RFC PATCH 2/4] dm-crypt: Skip encryption of file system-encrypted blocks Michael Halcrow
2017-06-14 23:40 ` [RFC PATCH 3/4] ext4: Set the bio REQ_NOENCRYPT flag Michael Halcrow
2017-06-14 23:40 ` [RFC PATCH 4/4] f2fs: " Michael Halcrow
2017-06-15 7:33 ` [dm-crypt] [RFC PATCH 0/4] Allow file systems to selectively bypass dm-crypt Milan Broz
2017-06-15 7:33 ` Milan Broz
2017-06-15 17:24 ` [dm-crypt] " Michael Halcrow
2017-06-15 17:24 ` Michael Halcrow
2017-06-15 18:17 ` [dm-crypt] " Milan Broz
2017-06-15 18:17 ` Milan Broz
2017-06-16 18:42 ` [dm-crypt] " Michael Halcrow
2017-06-16 18:42 ` Michael Halcrow
2017-06-20 14:44 ` [dm-crypt] " Mike Snitzer
2017-06-20 14:44 ` Mike Snitzer
2017-06-16 12:55 ` [dm-crypt] " 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.