From: Eric Biggers <email@example.com> To: Ahmad Fatoum <firstname.lastname@example.org> Cc: Sumit Garg <email@example.com>, "Theodore Y. Ts'o" <firstname.lastname@example.org>, Jaegeuk Kim <email@example.com>, Jarkko Sakkinen <firstname.lastname@example.org>, James Morris <email@example.com>, "Serge E. Hallyn" <firstname.lastname@example.org>, James Bottomley <email@example.com>, Mimi Zohar <firstname.lastname@example.org>, David Howells <email@example.com>, firstname.lastname@example.org, "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" <email@example.com>, linux-integrity <firstname.lastname@example.org>, "open list:SECURITY SUBSYSTEM" <email@example.com>, "open list:ASYMMETRIC KEYS" <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, firstname.lastname@example.org, Omar Sandoval <email@example.com>, Pengutronix Kernel Team <firstname.lastname@example.org> Subject: Re: [RFC PATCH v1] fscrypt: support encrypted and trusted keys Date: Thu, 29 Jul 2021 11:28:11 -0700 [thread overview] Message-ID: <YQLzOwnPF1434kUk@gmail.com> (raw) In-Reply-To: <email@example.com> On Thu, Jul 29, 2021 at 11:07:00AM +0200, Ahmad Fatoum wrote: > >> Most people don't change defaults. > >> > >> Essentially your same argument was used for Dual_EC_DRBG; people argued it was > >> okay to standardize because people had the option to choose their own constants > >> if they felt the default constants were backdoored. That didn't really matter, > >> though, since in practice everyone just used the default constants. > > I'd appreciate your feedback on my CAAM series if you think the defaults > can be improved. Trusted keys are no longer restricted to TPMs, > so users of other backends shouldn't be dismissed, because one backend > can be used with fscrypt by alternative means. I already gave feedback: https://lkml.kernel.org/keyrings/YGOcZtkw3ZM5kvl6@gmail.com https://lkml.kernel.org/keyrings/YGUHBelwhvJDhKoo@gmail.com https://lkml.kernel.org/keyrings/YGViOc3DG+Pjuur6@sol.localdomain > >>>> - trusted and encrypted keys aren't restricted to specific uses in the kernel > >>>> (like the fscrypt-provisioning key type is) but rather are general-purpose. > >>>> Hence, it may be possible to leak their contents to userspace by requesting > >>>> their use for certain algorithms/features, e.g. to encrypt a dm-crypt target > >>>> using a weak cipher that is vulnerable to key recovery attacks. > >>> > >>> The footgun is already there by allowing users to specify their own > >>> > >>> raw key. Users can already use $keyid for dm-crypt and then do > >>> > >>> $ keyctl pipe $keyid | fscryptctl add_key /mnt > >>> > >>> The responsibility to not reuse key material already lies with the users, > >>> regardless if they handle the raw key material directly or indirectly via > >>> a trusted key description/ID. > >> > >> Elsewhere you are claiming that "trusted" keys can never be disclosed to > >> userspace. So you can't rely on userspace cooperating, right? > > The users I meant are humans, e.g. system integrators. They need to think about > > burning fuses, signing bootloaders, verifying kernel and root file systems, > > encrypting file systems and safekeeping their crypto keys. Ample opportunity for > > stuff to go wrong. They would benefit from having relevant kernel functionality > > integrate with each other instead of having to carry downstream patches, which > we and many others did for years. We now finally have a chance to drop this > technical debt thanks to Sumit's trusted key rework and improve user security > along the way. > > So, Eric, how should we proceed? > It is probably inevitable that this be added, but you need to document it properly and not make misleading claims like "The key material is generated within the kernel" (for the TPM "trust" source the default is to use the TPM's RNG, *not* the kernel RNG), and "is never disclosed to userspace in clear text" (that's only guaranteed to be true for non-malicious userspace). Also please properly document that this is mainly intended for accessing key wrapping hardware such as CAAM that can't be accessed from userspace in another way like TPMs can. - Eric
next prev parent reply other threads:[~2021-07-29 18:28 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-27 14:43 Ahmad Fatoum 2021-07-27 16:38 ` Eric Biggers 2021-07-28 8:50 ` Ahmad Fatoum 2021-07-28 16:05 ` Eric Biggers 2021-07-29 5:56 ` Sumit Garg 2021-07-29 9:07 ` Ahmad Fatoum 2021-07-29 18:28 ` Eric Biggers [this message] 2021-07-28 22:22 ` Jarkko Sakkinen 2021-07-28 22:27 ` Ahmad Fatoum
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YQLzOwnPF1434kUk@gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [RFC PATCH v1] fscrypt: support encrypted and trusted keys' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).