[dm-devel] [LSF/MM/BPF TOPIC] Linux Security Summit cross-over?

[Steve French]

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.Bottomley at 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20230224/8564bf0b/attachment.htm>