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

From: John Stoffel
Date: Thu Oct 24 2024 - 15:22:47 EST


>>>>> "Adrian" == Adrian Vovk <adrianvovk@xxxxxxxxx> writes:

> On Thu, Oct 24, 2024 at 4:11 AM Geoff Back <geoff@xxxxxxxxxxxxxxx> wrote:
>>
>>
>> On 24/10/2024 03:52, Adrian Vovk wrote:
>> > On Wed, Oct 23, 2024 at 2:57 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
>> >> On Fri, Oct 18, 2024 at 11:03:50AM -0400, Adrian Vovk wrote:
>> >>> 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.
>>
>> As an encrypted-systems administrator, I would actively expect and
>> require that stacked encryption layers WOULD each encrypt. If I have
>> set up full disk encryption, then as an administrator I expect that to
>> be obeyed without exception, regardless of whether some higher level
>> file system has done encryption already.
>>
>> Anything that allows a higher level to bypass the full disk encryption
>> layer is, in my opinion, a bug and a serious security hole.

> Sure I'm sure there's usecases where passthrough doesn't make sense.
> It should absolutely be an opt-in flag on the dm target, so you the
> administrator at setup time can choose whether or not you perform
> double-encryption (and it defaults to doing so). Because there are
> usecases where it doesn't matter, and for those usecases we'd set
> the flag and allow passthrough for performance reasons.

If you're so concerend about security that you're double or triple
encrypting data at various layers, then obviously skipping encryption
at a lower layer just because an upper layer says "He, I already
encrypted this!" just doesn't make any sense.

So how does your scheme defend against bad actors? I'm on a system
with an encrypted disk. I make a file and mount it with loop, and the
encrypt it. But it's slow! So I turn off encryption. Now I shutdown
the loop device cleanly, unmount, and reboot the system. So what
should I be seing in those blocks if I examine the plain file that's
now not mounted?

Could this be a way to smuggle data out because now the data written
to the low level disk is encypted with a much weaker algorithm? So I
can just take the system disk and read the raw data and find the data?

I'm not saying it's going to be easy or simple, but is it possible?

John