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. > 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. > 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. > In my loopback file scenario, what would be the one layer that could > handle the encryption? But getting rid of loopback devices.
