linux-kernel - Re: [PATCH v2 1/3] dm-inlinecrypt: Add inline encryption support

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: <D96294E2-F17A-4E58-90FB-1D17747048E5@gmail.com>
Date: Fri, 18 Oct 2024 11:03:50 -0400
From: Adrian Vovk <adrianvovk@...il.com>
To: Christoph Hellwig <hch@...radead.org>
CC: Eric Biggers <ebiggers@...nel.org>, Md Sadre Alam <quic_mdalam@...cinc.com>,
 axboe@...nel.dk, song@...nel.org, yukuai3@...wei.com, agk@...hat.com,
 snitzer@...nel.org, Mikulas Patocka <mpatocka@...hat.com>,
 adrian.hunter@...el.com, quic_asutoshd@...cinc.com, ritesh.list@...il.com,
 ulf.hansson@...aro.org, andersson@...nel.org, konradybcio@...nel.org,
 kees@...nel.org, gustavoars@...nel.org, linux-block@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-raid@...r.kernel.org,
 dm-devel@...ts.linux.dev, linux-mmc@...r.kernel.org,
 linux-arm-msm@...r.kernel.org, linux-hardening@...r.kernel.org,
 quic_srichara@...cinc.com, quic_varada@...cinc.com
Subject: Re: [PATCH v2 1/3] dm-inlinecrypt: Add inline encryption support

On October 18, 2024 1:56:38 AM EDT, Christoph Hellwig <hch@...radead.org> wrote:
>On Fri, Oct 18, 2024 at 01:44:19AM -0400, Adrian Vovk wrote:
>> > So just run a target on each partition.
>> 
>> 
>> That has different semantics. If I encrypt each virtual partition there's
>> nothing encrypting the metadata around the virtual partitions. Of course,
>> this is a rather contrived example but point stands, the semantics are
>> different.
>
>Then you set up an dm-crype device mapper table for the partition table as
>well.

Sure, but then this way you're encrypting each partition twice. Once by the dm-crypt inside of the partition, and again by the dm-crypt that's under the partition table. This double encryption is ruinous for performance, so it's just not a feasible solution and thus people don't do this. Would be nice if we had the flexibility though.

Plus, I'm not sure that such a double encryption approach is even feasible with blk-crypto. Is the blk-crypto engine capable of receiving two keys and encrypting twice with them?

>
>> > This is the prime example of why allowing higher layers to skip
>> > encryption is a no-go.
>> >
>> 
>> In what way does that break the file system's security model? Could you
>> elaborate on what's objectionable about the behavior here?
>
>Because you are now bypassing encryption for certainl LBA ranges in
>the file system based on hints/flags for something sitting way above
>in the stack.
>

Well the data is still encrypted. It's just encrypted with a different key. If the attacker has a FDE dump of the disk, the data is still just as inaccessible to them.

In fact, allowing for this will let us tighten up security instead of punching holes. It would let us put encrypted home directories on top of full-disk encryption. So if an attacker has a disk image and the FDE key, they still wouldn't be able to decrypt the user's home directory because they'd need more keys. We also want to put fscrypt on top of the encrypted home directories to encrypt each app data directory, so if you have a banking app the attacker wouldn't be able to get that app's data even if they manage to get your home directory key. Right now, doing something like this requires stacking encryption and is thus unfeasible and we can't do it, so we're stuck with one layer of full disk encryption and no isolation between users and apps.

Thanks,
Adrian