On Thu, Oct 24, 2024 at 11:59 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Thu, Oct 24, 2024 at 11:32:58AM -0400, Adrian Vovk wrote: > > >> I'm not assuming. That's the behavior of dm-crypt without passthrough. > > >> It just encrypts everything that moves through it. If I stack two > > >> layers of dm-crypt on top of each other my data is encrypted twice. > > > > > >Sure. But why would you do that? > > > > As mentioned earlier in the thread: I don't have a usecase > > specifically for this and it was an example of a situation where > > passthrough is necessary and no filesystem is involved at all. Though, > > as I also pointed out, a usecase where you're putting encrypted > > virtual partitions on an encrypted LVM setup isn't all that absurd. > > It's a little odd but not entirely absurd indeed. But it can also > be easily handled by setting up a dm-crypt table just for the > partition table. That doesn't cover it. Not all of the virtual partitions necessarily need to have their own dm-crypt, so they should be encrypted by the underlying dm-crypt. So the dm-crypt doesn't just need to cover the partition table, but also arbitrary ranges within the whole partition > > In my real-world case, I'm putting encrypted loop devices on top of a > > filesystem that holds its own sensitive data. Each loop device has > > dm-crypt inside and uses a unique key, but the filesystem needs to be > > encrypted too (because, again, it has its own sensitive data outside > > of the loop devices). The loop devices cannot be put onto their own > > separate partition because there's no good way to know ahead of time > > how much space either of the partitions would need: sometimes the loop > > devices need to take up loads of space on the partition, and other > > times the non-loop-device data needs to take up that space. And to top > > it all off, the distribution of allocated space needs to change > > dynamically. > > And that's exactly the case I worry about. The file system can't > trust a layer entirely above it. If we want to be able to have a > space pool between a file systems with one encryption policy and > images with another we'll need to replace the loop driver with a > block driver taking blocks from the file system space pool. Which > might be a good idea for various other reasons. I don't quite understand the difference between a loopback file, and a block driver that uses space from a filesystem space pool. Isn't that what a loopback file is? > > > Ultimately, I'm unsure what the concern is here. > > > > It's a glaringly loud opt-in marker that encryption was already > > performed or is otherwise intentionally unnecessary. The flag existing > > isn't what punches through the security model. It's the use of the > > flag that does. I can't imagine anything setting the flag by accident. > > So what are you actually concerned about? How are you expecting this > > flag to actually be misused? > > > > As for third party modules that might punch holes, so what? 3rd party > > modules aren't the kernel's responsibility or problem > > On the one hand they are not. On the other if you have a file system > encryption scheme that is bypassed by a random other loadable code > setting a single flag I would not consider it very trust worth or in > fact actively dangerous. I'd expect that the lower encryption layer has an opt-in flag to turn on and off passthrough functionality. I think I neglected to mention that before; it was discussed in other threads and I just kinda assumed that it would be there. So, with that in mind: the loadable code could set the flag, but the underlying dm-inlinecrypt would need to opt into the weaker security too. If the system administrator has opted the lower layer into passthrough, then they've considered the risks of what could happen if an upper layer sets the flag and decided that it's OK. If the administrator didn't opt in, then the flag has no effect. Does that sound more acceptable? > > > In my loopback file scenario, what would be the one layer that could > > handle the encryption? > > But getting rid of loopback devices. I can't get rid of the loopback devices. They're an essential part of this. I should be able to take the encrypted loopback file, send it to a different machine, and have it keep working the same as it always has. Without the loopback device, I'm stuck with fscrypt. Which isn't supported by all filesystems, and encrypts much less data than we require. - Adrian
