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."
As a possible alternative I suggested limiting which file hashes the
certs on the secondary (or machine) keyring could blacklist.
--
thanks,
Mimi
