<div dir="auto">I did one on network fs security at a security summit before that would still be relevant to both</div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 21, 2023, 16:16 James Bottomley <<a href="mailto:James.Bottomley@hansenpartnership.com">James.Bottomley@hansenpartnership.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 </blockquote></div>