From: Eric Snowberg <firstname.lastname@example.org> To: "Mickaël Salaün" <email@example.com> Cc: "David Howells" <firstname.lastname@example.org>, "David Woodhouse" <email@example.com>, "Jarkko Sakkinen" <firstname.lastname@example.org>, "David S . Miller" <email@example.com>, "Herbert Xu" <firstname.lastname@example.org>, "James Morris" <email@example.com>, "Mickaël Salaün" <firstname.lastname@example.org>, "Mimi Zohar" <email@example.com>, "Serge E . Hallyn" <firstname.lastname@example.org>, "Tyler Hicks" <email@example.com>, firstname.lastname@example.org, email@example.com, linux-integrity <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH v7 5/5] certs: Allow root user to append signed hashes to the blacklist keyring Date: Wed, 17 Mar 2021 08:48:11 -0600 Message-ID: <5111D396-9910-48E9-8D91-6433E719EDB5@oracle.com> (raw) In-Reply-To: <email@example.com> > On Mar 15, 2021, at 12:01 PM, Mickaël Salaün <firstname.lastname@example.org> wrote: > > > On 15/03/2021 17:59, Eric Snowberg wrote: >> >>> On Mar 12, 2021, at 10:12 AM, Mickaël Salaün <email@example.com> wrote: >>> >>> From: Mickaël Salaün <firstname.lastname@example.org> >>> >>> Add a kernel option SYSTEM_BLACKLIST_AUTH_UPDATE to enable the root user >>> to dynamically add new keys to the blacklist keyring. This enables to >>> invalidate new certificates, either from being loaded in a keyring, or >>> from being trusted in a PKCS#7 certificate chain. This also enables to >>> add new file hashes to be denied by the integrity infrastructure. >>> >>> Being able to untrust a certificate which could have normaly been >>> trusted is a sensitive operation. This is why adding new hashes to the >>> blacklist keyring is only allowed when these hashes are signed and >>> vouched by the builtin trusted keyring. A blacklist hash is stored as a >>> key description. The PKCS#7 signature of this description must be >>> provided as the key payload. >>> >>> Marking a certificate as untrusted should be enforced while the system >>> is running. It is then forbiden to remove such blacklist keys. >>> >>> Update blacklist keyring, blacklist key and revoked certificate access rights: >>> * allows the root user to search for a specific blacklisted hash, which >>> make sense because the descriptions are already viewable; >>> * forbids key update (blacklist and asymmetric ones); >>> * restricts kernel rights on the blacklist keyring to align with the >>> root user rights. >>> >>> See help in tools/certs/print-cert-tbs-hash.sh . >>> >>> Cc: David Howells <email@example.com> >>> Cc: David Woodhouse <firstname.lastname@example.org> >>> Cc: Eric Snowberg <email@example.com> >>> Cc: Jarkko Sakkinen <firstname.lastname@example.org> >>> Signed-off-by: Mickaël Salaün <email@example.com> >>> Link: https://firstname.lastname@example.org >> >> I tried testing this, it doesn’t work as I would expect. >> Here is my test setup: >> >> Kernel built with two keys compiled into the builtin_trusted_keys keyring >> >> Generated a tbs cert from one of the keys and signed it with the other key >> >> As root, added the tbs cert hash to the blacklist keyring >> >> Verified the tbs hash is in the blacklist keyring >> >> Enabled lockdown to enforce kernel module signature checking >> >> Signed a kernel module with the key I just blacklisted >> >> Load the kernel module >> >> I’m seeing the kernel module load, I would expect this to fail, since the >> key is now blacklisted. Or is this change just supposed to prevent new keys >> from being added in the future? > > This is the expected behavior and the way the blacklist keyring is > currently used, as explained in the commit message: > "This enables to invalidate new certificates, either from being loaded > in a keyring, or from being trusted in a PKCS#7 certificate chain." > > If you want a (trusted root) key to be untrusted, you need to remove it > from the keyring, which is not allowed for the builtin trusted keyring. Is there a non technical reason why this can not be changed to also apply to builtin trusted keys? If a user had the same tbs cert hash in their dbx and soon mokx, the hash would show up in the .blacklist keyring and invalidate any key in the builtin_trusted_keys keyring. After adding the same hash with this series, it shows up in the .blacklist_keyring but the value is ignored by operations using the builtin_trusted_keys keyring. It just seems incomplete to me, or did I miss an earlier discussion on this topic?
next prev parent reply index Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-12 17:12 [PATCH v7 0/5] Enable root to update " Mickaël Salaün 2021-03-12 17:12 ` [PATCH v7 1/5] tools/certs: Add print-cert-tbs-hash.sh Mickaël Salaün 2021-03-15 16:57 ` Eric Snowberg 2021-03-12 17:12 ` [PATCH v7 2/5] certs: Check that builtin blacklist hashes are valid Mickaël Salaün 2021-03-13 18:53 ` Jarkko Sakkinen 2021-03-12 17:12 ` [PATCH v7 3/5] certs: Make blacklist_vet_description() more strict Mickaël Salaün 2021-03-12 17:12 ` [PATCH v7 4/5] certs: Factor out the blacklist hash creation Mickaël Salaün 2021-03-13 18:54 ` Jarkko Sakkinen 2021-03-12 17:12 ` [PATCH v7 5/5] certs: Allow root user to append signed hashes to the blacklist keyring Mickaël Salaün 2021-03-15 16:59 ` Eric Snowberg 2021-03-15 18:01 ` Mickaël Salaün 2021-03-17 14:48 ` Eric Snowberg [this message] 2021-03-17 15:45 ` Mickaël Salaün 2021-03-25 11:36 ` [PATCH v7 0/5] Enable root to update " Mickaël Salaün 2021-04-07 17:21 ` Mickaël Salaün 2021-05-04 10:31 ` Mickaël Salaün
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=5111D396-9910-48E9-8D91-6433E719EDB5@oracle.com \ --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 \ /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
Linux-Security-Module Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-security-module/0 linux-security-module/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-security-module linux-security-module/ https://lore.kernel.org/linux-security-module \ firstname.lastname@example.org public-inbox-index linux-security-module Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-security-module AGPL code for this site: git clone https://public-inbox.org/public-inbox.git