linux-ext4 - Re: [RFC PATCH 0/4] Allow file systems to selectively bypass dm-crypt

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0df74dd8-f29d-8925-7cc1-783d09c6a42c@gmail.com>
Date:   Thu, 15 Jun 2017 20:17:02 +0200
From:   Milan Broz <gmazyland@...il.com>
To:     Michael Halcrow <mhalcrow@...gle.com>
Cc:     "Theodore Y . Ts'o" <tytso@....edu>,
        Eric Biggers <ebiggers@...gle.com>,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        linux-fscrypt@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-block@...r.kernel.org, dm-devel@...hat.com,
        linux-ext4@...r.kernel.org,
        Tyler Hicks <tyler.hicks@...onical.com>,
        dm-crypt <dm-crypt@...ut.de>
Subject: Re: [RFC PATCH 0/4] Allow file systems to selectively bypass dm-crypt

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.

Obvious solution is to implement encryption in fs properly and encrypt
fs metadata there. I guess this is your long term goal?

Is the double encryption really such a big problem?
With some hw support it should not cost much time and energy.
Do you have some numbers to show that is it real problem?

What I am missing here is the definition of your threat model.

If the encryption of metadata in block layer is ok for you, why it is not
ok for the data?

What are you solving there? Is it that one user must not see other users data?
(And who is an user on a mobile device - an application in own sandbox?)

Because the confidentiality in the case of stolen device is there with
encryption on any layer. And ext4 encryption uses the same algorithms
as dmcrypt IIRC.

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 am not sure how complicated this would be to implement but we have already
concept of multiple keys in dmcrypt (there is 64 keys for loopAES mapping
and the used key id is calculated as sector# modulo 64).

Maybe the keys can be taken from kernel keyring and loaded dynamically,
according to optional table parameters that defines policy for it.
The IV could be shared (in XTS mode it is not a problem).
If the key is not available, the bio should simply fail early.

Dunno, just an idea - it really depends what are you trying to solve.

Milan