The initial subject was "Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring": https://lore.kernel.org/all/20230908213428.731513-1-eric.snowberg@xxxxxxxxxx/ On Thu, Sep 14, 2023 at 10:34:44AM +0200, Mickaël Salaün wrote: > CCing the LSM mailing list for this potential new LSM proposal: > > On Wed, Sep 13, 2023 at 10:29:58PM +0000, Eric Snowberg wrote: > > > > > > > On Sep 13, 2023, at 4:21 AM, Mickaël Salaün <mic@xxxxxxxxxxx> wrote: > > > > > > On Wed, Sep 13, 2023 at 02:40:17AM +0000, Eric Snowberg wrote: > > >> > > >> > > >>> On Sep 12, 2023, at 4:47 PM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > >>> > > >>> On Tue, 2023-09-12 at 17:11 +0000, Eric Snowberg wrote: > > >>>> > > >>>>> On Sep 12, 2023, at 5:54 AM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > >>>>> > > >>>>> On Tue, 2023-09-12 at 02:00 +0000, Eric Snowberg wrote: > > >>>>>> > > >>>>>>> On Sep 11, 2023, at 5:08 PM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > >>>>>>> > > >>>>>>> On Mon, 2023-09-11 at 22:17 +0000, Eric Snowberg wrote: > > >>>>>>>> > > >>>>>>>>> On Sep 11, 2023, at 10:51 AM, Mickaël Salaün <mic@xxxxxxxxxxx> wrote: > > >>>>>>>>> > > >>>>>>>>> On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote: > > >>>>>>>>>> Hi Eric, > > >>>>>>>>>> > > >>>>>>>>>> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote: > > >>>>>>>>>>> Currently root can dynamically update the blacklist keyring if the hash > > >>>>>>>>>>> being added is signed and vouched for by the builtin trusted keyring. > > >>>>>>>>>>> Currently keys in the secondary trusted keyring can not be used. > > >>>>>>>>>>> > > >>>>>>>>>>> Keys within the secondary trusted keyring carry the same capabilities as > > >>>>>>>>>>> the builtin trusted keyring. Relax the current restriction for updating > > >>>>>>>>>>> the .blacklist keyring and allow the secondary to also be referenced as > > >>>>>>>>>>> a trust source. Since the machine keyring is linked to the secondary > > >>>>>>>>>>> trusted keyring, any key within it may also be used. > > >>>>>>>>>>> > > >>>>>>>>>>> An example use case for this is IMA appraisal. Now that IMA both > > >>>>>>>>>>> references the blacklist keyring and allows the machine owner to add > > >>>>>>>>>>> custom IMA CA certs via the machine keyring, this adds the additional > > >>>>>>>>>>> capability for the machine owner to also do revocations on a running > > >>>>>>>>>>> system. > > >>>>>>>>>>> > > >>>>>>>>>>> IMA appraisal usage example to add a revocation for /usr/foo: > > >>>>>>>>>>> > > >>>>>>>>>>> sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt > > >>>>>>>>>>> > > >>>>>>>>>>> openssl smime -sign -in hash.txt -inkey machine-private-key.pem \ > > >>>>>>>>>>> -signer machine-certificate.pem -noattr -binary -outform DER \ > > >>>>>>>>>>> -out hash.p7s > > >>>>>>>>>>> > > >>>>>>>>>>> keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s > > >>>>>>>>>>> > > >>>>>>>>>>> Signed-off-by: Eric Snowberg <eric.snowberg@xxxxxxxxxx> > > >>>>>>>>>> > > >>>>>>>>>> The secondary keyring may include both CA and code signing keys. With > > >>>>>>>>>> this change any key loaded onto the secondary keyring may blacklist a > > >>>>>>>>>> hash. Wouldn't it make more sense to limit blacklisting > > >>>>>>>>>> certificates/hashes to at least CA keys? > > >>>>>>>>> > > >>>>>>>>> Some operational constraints may limit what a CA can sign. > > >>>>>>>> > > >>>>>>>> Agreed. > > >>>>>>>> > > >>>>>>>> Is there precedents for requiring this S/MIME to be signed by a CA? > > >>>>>>>> > > >>>>>>>>> This change is critical and should be tied to a dedicated kernel config > > >>>>>>>>> (disabled by default), otherwise existing systems using this feature > > >>>>>>>>> will have their threat model automatically changed without notice. > > >>>>>>>> > > >>>>>>>> Today we have INTEGRITY_CA_MACHINE_KEYRING_MAX. This can > > >>>>>>>> be enabled to enforce CA restrictions on the machine keyring. Mimi, would > > >>>>>>>> this be a suitable solution for what you are after? > > >>>>>>> > > >>>>>>> There needs to be some correlation between the file hashes being added > > >>>>>>> to the blacklist and the certificate that signed them. Without that > > >>>>>>> correlation, any key on the secondary trusted keyring could add any > > >>>>>>> file hashes it wants to the blacklist. > > >>>>>> > > >>>>>> Today any key in the secondary trusted keyring can be used to validate a > > >>>>>> signed kernel module. At a later time, if a new hash is added to the blacklist > > >>>>>> keyring to revoke loading a signed kernel module, the ability to do the > > >>>>>> revocation with this additional change would be more restrictive than loading > > >>>>>> the original module. > > >>>>> > > >>>>> A public key on the secondary keyring is used to verify code that it > > >>>>> signed, but does not impact any other code. Allowing any public key on > > >>>>> the secondary keyring to blacklist any file hash is giving it more > > >>>>> privileges than it originally had. > > >>>>> > > >>>>> This requirement isn't different than how Certificate Revocation List > > >>>>> (CRL) work. Not any CA can revoke a certificate. > > >>>> > > >>>> In UEFI Secure Boot we have the Forbidden Signature Database (DBX). > > >>>> Root can update the DBX on a host. The requirement placed on updating > > >>>> it is the new DBX entry must be signed by any key contained within the > > >>>> KEK. Following a reboot, all DBX entries load into the .blacklist keyring. > > >>>> There is not a requirement similar to how CRL’s work here, any KEK key > > >>>> can be used. > > >>>> > > >>>> With architectures booted through a shim there is the MOKX. Similar to > > >>>> DBX, MOKX have the same capabilities, however they do not need to be > > >>>> signed by any key, the machine owner must show they have physical > > >>>> presence (and potentially a MOK password) for inclusion. Again there > > >>>> is not a requirement similar to how CRL’s work here either. The machine > > >>>> owner can decide what is included. > > >>>> > > >>>> Today when a kernel is built, any number of keys may be included within > > >>>> the builtin trusted keyring. The keys included in the kernel may not have > > >>>> a single usage field set or the CA bit set. There are no requirements on > > >>>> how these keys get used later on. Any key in the builtin trusted keyring > > >>>> can be used to sign a revocation that can be added to the blacklist keyring. > > >>>> Additionally, any key in the MOK can be used to sign this kernel and it will > > >>>> boot. Before booting the kernel, MOK keys have more privileges than > > >>>> after the kernel is booted in some instances. > > >>>> > > >>>> Today MOK keys can be loaded into the machine keyring. These keys get > > >>>> linked to the secondary trusted keyring. Currently key usage enforcement > > >>>> is being applied to these keys behind some Kconfig options. By default > > >>>> anything in the secondary has the same capabilities as the builtin trusted > > >>>> keyring. What is challenging here with this request is the inconsistency > > >>>> between how everything else currently works. > > >>>> > > >>>> Root can not arbitrarily add things to the secondary trusted keyring. These > > >>>> keys must be signed by something in either the machine or the builtin. In > > >>>> this thread [1], Jarkko is saying CA based infrastructure should be a policy > > >>>> decision not to be enforced by the kernel. Wouldn’t this apply here as well? > > >>>> > > >>>> 1. https://lore.kernel.org/lkml/CVGUFUEQVCHS.37OA20PNG9EVB@suppilovahvero/ > > >>> > > >>> Mickaël said, "This change is critical and should be tied to a > > >>> dedicated kernel config > > >>> (disabled by default), otherwise existing systems using this feature > > >>> will have their threat model automatically changed without notice." > > >> > > >> I was thinking he meant it is critical not to change the current behavior > > >> by limiting blacklisting to only CA keys. Not that it was critical to add > > >> CA enforcement. Maybe Mickaël can comment? > > > > > > I meant that applying this patch as-is may change the threat model used > > > by some users. Currently, only signed hashes vouched by the builtin > > > trusted keyring are valid. If we extend this mechanism to the secondary > > > trusted keyring without notice, this means that more certificates could > > > vouch blacklisted hashes, which may include some certificates with an > > > initial different usage. > > > > > > See commit 4da8f8c8a1e0 ("dm verity: Add support for signature > > > verification with 2nd keyring") that adds > > > CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING: > > > https://lore.kernel.org/all/20201023170512.201124-1-mic@xxxxxxxxxxx/ > > > > Thanks for clarifying. I’ll add something similar in v2. > > > > >> > > >>> As a possible alternative I suggested limiting which file hashes the > > >>> certs on the secondary (or machine) keyring could blacklist. > > >> > > >> I’m not sure I completely understand your suggestion here. > > >> Do you mean, verify the CA bit is set for secondary keys, but > > >> ignore the bit for builtin? And then only use those keys to add > > >> hashes to the blacklist keyring? If I have that right, what would > > >> be the justification for the change based on how things currently > > >> get included in the blacklist keyring? Thanks. > > > > > > I'd like to be able to specify which kind of certificate can vouch for > > > blacklisting hashes, and for other usages, but AFAIK this is not the > > > path Linux has followed (e.g. unlike Windows). We only have the keyring > > > to identify an usage, which is unfortunate. On the other side, this > > > approach lets users manage their certificates without constraint, which > > > is quite (too?) flexible. > > > > Yes, it is very flexible. What I believe Mimi is after is having a way to > > track what cert actually vouched for each specific binary hash. But this > > information is not tracked, plus entries within it can come from various > > sources that are not signed (dbx, mokx, compiled in). Also key usage is > > being ignored. > > > > > A complementary approach would be to create an > > > LSM (or a dedicated interface) to tie certificate properties to a set of > > > kernel usages, while still letting users configure these constraints. > > > > That is an interesting idea. Would the other security maintainers be in > > support of such an approach? Would a LSM be the correct interface? > > Some of the recent work I have done with introducing key usage and CA > > enforcement is difficult for a distro to pick up, since these changes can be > > viewed as a regression. Each end-user has different signing procedures > > and policies, so making something work for everyone is difficult. Letting the > > user configure these constraints would solve this problem. > >
