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