On Wed, 2019-03-13 at 12:44 -0400, Theodore Ts'o wrote: > On Wed, Mar 13, 2019 at 08:36:34AM -0700, James Bottomley wrote: > > On Wed, 2019-03-13 at 11:16 -0400, Theodore Ts'o wrote: > > > So before we talk about how to make things work from a technical > > > perspective, we should consider what the use case happens to be, > > > and what are the security requirements. *Why* are we trying to > > > use the combination of overlayfs and fscrypt, and what are the > > > security properties we are trying to provide to someone who is > > > relying on this combination? > > > > I can give one: encrypted containers: > > > > https://github.com/opencontainers/image-spec/issues/747 > > > > The current proposal imagines that the key would be delivered to > > the physical node and the physical node containerd would decrypt > > all the layers before handing them off to to the kubelet. However, > > one could imagine a slightly more secure use case where the layers > > were constructed as an encrypted filesystem tar and so the key > > would go into the kernel and the layers would be constructed with > > encryption in place using fscrypt. > > > > Most of the desired security properties are in image at rest but > > one can imagine that the running image wants some protection > > against containment breaches by other tenants and using fscrypt > > could provide that. > > What kind of containment breaches? If they can break root, it's all > over no matter what sort of encryption you are using. With me it's always unprivileged containers inside a user_ns, so containment breach means non-root. I hope eventually this will be the norm for the container industry as well. > If they can't break root, then the OS's user-id based access > control checks (or SELinux checks if you are using SELinux) will > still protect you. Well, that's what one would think about the recent runc exploit as well. The thing I was looking to do was reduce the chances that unencrypted data would be lying around to be discovered. I suppose the potentially biggest problem is leaking the image after it's decrypted by admin means like a badly configured backup, but unencryped data is potentially discoverable by breakouts as well. James
