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

[Hannes Reinecke]

On 2/24/23 22:37, Steve French wrote:
> 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 
> <mailto: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?
> That's one where I'd be interested in, too; for NVMe-over-TLS we'll be 
using keyrings, too, and have the same issue as to how and where keys 
should be decoded (eg for X.509 handling).

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare at suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman