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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux