I did one on network fs security at a security summit before that would still be relevant to both
On Tue, Feb 21, 2023, 16:16 James Bottomley < james.bottom...@hansenpartnership.com> wrote: > On Tue, 2023-02-21 at 16:55 +0000, David Howells wrote: > > > > Since the first day of the LSS is the same as the final day of LSF > > and in the same venue, are there any filesystem + security subjects > > that would merit a common session? > > > I've got one: Cryptographic material handling. > > Subtitle could be: making keyrings more usable. > > The broad problem is that the use of encryption within the kernel is > growing (from the old dm-crypt to the newer fscrypt and beyond) yet > pretty much all of our cryptographic key material handling violates the > principle of least privilege. The latest one (which I happened to > notice being interested in TPMs) is the systemd tpm2 cryptenroll. The > specific violation is that key unwrapping should occur as close as > possible to use: when the kernel uses a key, it should be the kernel > unwrapping it not unwrapping in user space and handing the unwrapped > key down to the kernel because that gives a way. We got here because > in most of the old uses, the key is derived from a passphrase and the > kernel can't prompt the user, so pieces of user space have to gather > the precursor cryptographic material anyway. However, we're moving > towards using cryptographic devices (like the TPM, key fobs and the > like) to store keys we really should be passing the wrapped key into > the kernel and letting it do the unwrap to preserve least privilege. > dm-crypt has some support for using kernel based TPM keys (the trusted > key subsystem), but this isn't propagated into systemd-cryptenroll and > pretty much none of the other encryption systems make any attempt to > use keyrings for unwrap handling, even if they use keyrings to store > cryptographic material. > > Part of the reason seems to be that the keyrings subsystem itself is > hard to use as a generic "unwrapper" since the consumer of the keys has > to know exactly the key type to consume the protected payload. We > could possibly fix this by adding a payload accessor function so the > keyring consumer could access a payload from any key type and thus > benefit from in-kernel unwrapping, but there are likely a host of other > issues that need to be solved. So what I'd really like to discuss is: > > Given the security need for a generic in-kernel unwrapper, should we > make keyrings do this and if so, how? > > Regards, > > James > > > >
-- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel