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@xxxxxxxxxxxxxxxxxxxxx
<mailto:James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>> 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@xxxxxxx +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
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
