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

[John Stoffel]

>>>>> "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