mbox series

[v1,0/9] Enable root to update the blacklist keyring

Message ID 20201120180426.922572-1-mic@digikod.net
Headers show
Series Enable root to update the blacklist keyring | expand

Message

Mickaël Salaün Nov. 20, 2020, 6:04 p.m. UTC
Hi,

This patch series mainly add a new configuration option to enable the
root user to load signed keys in the blacklist keyring.  This keyring is
useful to "untrust" certificates or files.  Enabling to safely update
this keyring without recompiling the kernel makes it more usable.

Regards,

Mickaël Salaün (9):
  certs: Fix blacklisted hexadecimal hash string check
  certs: Make blacklist_vet_description() more strict
  certs: Factor out the blacklist hash creation
  certs: Check that builtin blacklist hashes are valid
  PKCS#7: Fix missing include
  certs: Fix blacklist flag type confusion
  certs: Allow root user to append signed hashes to the blacklist
    keyring
  certs: Replace K{U,G}IDT_INIT() with GLOBAL_ROOT_{U,G}ID
  tools/certs: Add print-cert-tbs-hash.sh

 MAINTAINERS                                   |   2 +
 certs/.gitignore                              |   1 +
 certs/Kconfig                                 |  10 +
 certs/Makefile                                |  15 +-
 certs/blacklist.c                             | 210 +++++++++++++-----
 certs/system_keyring.c                        |   5 +-
 crypto/asymmetric_keys/x509_public_key.c      |   3 +-
 include/keys/system_keyring.h                 |  14 +-
 include/linux/verification.h                  |   2 +
 scripts/check-blacklist-hashes.awk            |  37 +++
 .../platform_certs/keyring_handler.c          |  26 +--
 tools/certs/print-cert-tbs-hash.sh            |  91 ++++++++
 12 files changed, 335 insertions(+), 81 deletions(-)
 create mode 100755 scripts/check-blacklist-hashes.awk
 create mode 100755 tools/certs/print-cert-tbs-hash.sh


base-commit: 09162bc32c880a791c6c0668ce0745cf7958f576

Comments

Jarkko Sakkinen Nov. 30, 2020, 2:40 a.m. UTC | #1
On Fri, Nov 20, 2020 at 07:04:17PM +0100, Mickaël Salaün wrote:
> Hi,

> 

> This patch series mainly add a new configuration option to enable the

> root user to load signed keys in the blacklist keyring.  This keyring is

> useful to "untrust" certificates or files.  Enabling to safely update

> this keyring without recompiling the kernel makes it more usable.


I apologize for latency. This cycle has been difficult because of
final cuts with the huge SGX patch set.

I did skim through this and did not see anything striking (but it
was a quick look).

What would be easiest way to smoke test the changes?

> Regards,

> 

> Mickaël Salaün (9):

>   certs: Fix blacklisted hexadecimal hash string check

>   certs: Make blacklist_vet_description() more strict

>   certs: Factor out the blacklist hash creation

>   certs: Check that builtin blacklist hashes are valid

>   PKCS#7: Fix missing include

>   certs: Fix blacklist flag type confusion

>   certs: Allow root user to append signed hashes to the blacklist

>     keyring

>   certs: Replace K{U,G}IDT_INIT() with GLOBAL_ROOT_{U,G}ID

>   tools/certs: Add print-cert-tbs-hash.sh

> 

>  MAINTAINERS                                   |   2 +

>  certs/.gitignore                              |   1 +

>  certs/Kconfig                                 |  10 +

>  certs/Makefile                                |  15 +-

>  certs/blacklist.c                             | 210 +++++++++++++-----

>  certs/system_keyring.c                        |   5 +-

>  crypto/asymmetric_keys/x509_public_key.c      |   3 +-

>  include/keys/system_keyring.h                 |  14 +-

>  include/linux/verification.h                  |   2 +

>  scripts/check-blacklist-hashes.awk            |  37 +++

>  .../platform_certs/keyring_handler.c          |  26 +--

>  tools/certs/print-cert-tbs-hash.sh            |  91 ++++++++

>  12 files changed, 335 insertions(+), 81 deletions(-)

>  create mode 100755 scripts/check-blacklist-hashes.awk

>  create mode 100755 tools/certs/print-cert-tbs-hash.sh

> 

> 

> base-commit: 09162bc32c880a791c6c0668ce0745cf7958f576

> -- 

> 2.29.2

> 

> 


/Jarkko
Mickaël Salaün Nov. 30, 2020, 8:23 a.m. UTC | #2
On 30/11/2020 03:40, Jarkko Sakkinen wrote:
> On Fri, Nov 20, 2020 at 07:04:17PM +0100, Mickaël Salaün wrote:

>> Hi,

>>

>> This patch series mainly add a new configuration option to enable the

>> root user to load signed keys in the blacklist keyring.  This keyring is

>> useful to "untrust" certificates or files.  Enabling to safely update

>> this keyring without recompiling the kernel makes it more usable.

> 

> I apologize for latency. This cycle has been difficult because of

> final cuts with the huge SGX patch set.

> 

> I did skim through this and did not see anything striking (but it

> was a quick look).

> 

> What would be easiest way to smoke test the changes?


An easy way to test it is to enable the second trusted keyring to
dynamically load certificates in the kernel. Then we can create a hash
of a valid certificate (but not loaded yet) and sign it as explained in
tools/certs/print-cert-tbs-hash.sh (patch 9/9). Once this hash is loaded
in the kernel, loading the blacklisted certificate will be denied. We
can also test it with a PKCS#7 signature chain, either with the
blacklist keyring itself, or with a signed dm-verity image.

> 

>> Regards,

>>

>> Mickaël Salaün (9):

>>   certs: Fix blacklisted hexadecimal hash string check

>>   certs: Make blacklist_vet_description() more strict

>>   certs: Factor out the blacklist hash creation

>>   certs: Check that builtin blacklist hashes are valid

>>   PKCS#7: Fix missing include

>>   certs: Fix blacklist flag type confusion

>>   certs: Allow root user to append signed hashes to the blacklist

>>     keyring

>>   certs: Replace K{U,G}IDT_INIT() with GLOBAL_ROOT_{U,G}ID

>>   tools/certs: Add print-cert-tbs-hash.sh

>>

>>  MAINTAINERS                                   |   2 +

>>  certs/.gitignore                              |   1 +

>>  certs/Kconfig                                 |  10 +

>>  certs/Makefile                                |  15 +-

>>  certs/blacklist.c                             | 210 +++++++++++++-----

>>  certs/system_keyring.c                        |   5 +-

>>  crypto/asymmetric_keys/x509_public_key.c      |   3 +-

>>  include/keys/system_keyring.h                 |  14 +-

>>  include/linux/verification.h                  |   2 +

>>  scripts/check-blacklist-hashes.awk            |  37 +++

>>  .../platform_certs/keyring_handler.c          |  26 +--

>>  tools/certs/print-cert-tbs-hash.sh            |  91 ++++++++

>>  12 files changed, 335 insertions(+), 81 deletions(-)

>>  create mode 100755 scripts/check-blacklist-hashes.awk

>>  create mode 100755 tools/certs/print-cert-tbs-hash.sh

>>

>>

>> base-commit: 09162bc32c880a791c6c0668ce0745cf7958f576

>> -- 

>> 2.29.2

>>

>>

> 

> /Jarkko

>
Jarkko Sakkinen Dec. 2, 2020, 4:44 p.m. UTC | #3
On Mon, Nov 30, 2020 at 09:23:59AM +0100, Mickaël Salaün wrote:
> 

> On 30/11/2020 03:40, Jarkko Sakkinen wrote:

> > On Fri, Nov 20, 2020 at 07:04:17PM +0100, Mickaël Salaün wrote:

> >> Hi,

> >>

> >> This patch series mainly add a new configuration option to enable the

> >> root user to load signed keys in the blacklist keyring.  This keyring is

> >> useful to "untrust" certificates or files.  Enabling to safely update

> >> this keyring without recompiling the kernel makes it more usable.

> > 

> > I apologize for latency. This cycle has been difficult because of

> > final cuts with the huge SGX patch set.

> > 

> > I did skim through this and did not see anything striking (but it

> > was a quick look).

> > 

> > What would be easiest way to smoke test the changes?

> 

> An easy way to test it is to enable the second trusted keyring to

> dynamically load certificates in the kernel. Then we can create a hash

> of a valid certificate (but not loaded yet) and sign it as explained in

> tools/certs/print-cert-tbs-hash.sh (patch 9/9). Once this hash is loaded

> in the kernel, loading the blacklisted certificate will be denied. We

> can also test it with a PKCS#7 signature chain, either with the

> blacklist keyring itself, or with a signed dm-verity image.


Thanks, looking into this once 5.11-rc1 is out.

/Jarkko
David Howells Dec. 4, 2020, 2:01 p.m. UTC | #4
Mickaël Salaün <mic@digikod.net> wrote:

> > What would be easiest way to smoke test the changes?

> 

> An easy way to test it is to enable the second trusted keyring to

> dynamically load certificates in the kernel. Then we can create a hash

> of a valid certificate (but not loaded yet) and sign it as explained in

> tools/certs/print-cert-tbs-hash.sh (patch 9/9). Once this hash is loaded

> in the kernel, loading the blacklisted certificate will be denied. We

> can also test it with a PKCS#7 signature chain, either with the

> blacklist keyring itself, or with a signed dm-verity image.


It might also be possible to use the pkcs#7 test key type
(CONFIG_PKCS7_TEST_KEY) to aid in that.

David
David Howells Dec. 4, 2020, 2:05 p.m. UTC | #5
Mickaël Salaün <mic@digikod.net> wrote:

> When looking for a blacklisted hash, bin2hex() is used to transform a

> binary hash to an ascii (lowercase) hexadecimal string.  This string is

> then search for in the description of the keys from the blacklist

> keyring.  When adding a key to the blacklist keyring,

> blacklist_vet_description() checks the hash prefix and the hexadecimal

> string, but not that this string is lowercase.  It is then valid to set

> hashes with uppercase hexadecimal, which will be silently ignored by the

> kernel.

> 

> Add an additional check to blacklist_vet_description() to check that

> hexadecimal strings are in lowercase.


I wonder if it would be a better idea to allow the keyring type to adjust the
description string - in this instance to change it to all lowercase.

David
David Howells Dec. 4, 2020, 2:06 p.m. UTC | #6
Mickaël Salaün <mic@digikod.net> wrote:

> +#include <stddef.h>


Something like linux/types.h is probably a better choice.

David
David Howells Dec. 4, 2020, 2:09 p.m. UTC | #7
Mickaël Salaün <mic@digikod.net> wrote:

> +	if (*desc)

> +		/* The hash is greater than MAX_HASH_LEN. */

> +		return -EINVAL;


-ENOPKG might be better.  It's not that the string is invalid, it's just that
it's unsupported at the moment.

David
Mickaël Salaün Dec. 4, 2020, 2:48 p.m. UTC | #8
On 04/12/2020 15:05, David Howells wrote:
> Mickaël Salaün <mic@digikod.net> wrote:

> 

>> When looking for a blacklisted hash, bin2hex() is used to transform a

>> binary hash to an ascii (lowercase) hexadecimal string.  This string is

>> then search for in the description of the keys from the blacklist

>> keyring.  When adding a key to the blacklist keyring,

>> blacklist_vet_description() checks the hash prefix and the hexadecimal

>> string, but not that this string is lowercase.  It is then valid to set

>> hashes with uppercase hexadecimal, which will be silently ignored by the

>> kernel.

>>

>> Add an additional check to blacklist_vet_description() to check that

>> hexadecimal strings are in lowercase.

> 

> I wonder if it would be a better idea to allow the keyring type to adjust the

> description string - in this instance to change it to all lowercase.


Right now, this patch helps user space identifies which hashes where
ignored. I think it is an interesting information on its own because it
enables to remove a false sense of security and warns about
mis-blacklisted certificates or binaries.

When authenticity/signature of such hash is taken into account, I also
prefer to not change the data that user space signed and pushed to the
kernel, but to teach user space what is correct.

Moreover, modifying the description cannot be done with the
vet_description-type function and would be a more invasive keyring
modification because, AFAIK, no current key type already does such change.

> 

> David

>
Mickaël Salaün Dec. 4, 2020, 2:58 p.m. UTC | #9
On 04/12/2020 15:06, David Howells wrote:
> Mickaël Salaün <mic@digikod.net> wrote:

> 

>> +#include <stddef.h>

> 

> Something like linux/types.h is probably a better choice.


Indeed.

> 

> David

>
Mickaël Salaün Dec. 4, 2020, 2:59 p.m. UTC | #10
On 04/12/2020 15:09, David Howells wrote:
> Mickaël Salaün <mic@digikod.net> wrote:

> 

>> +	if (*desc)

>> +		/* The hash is greater than MAX_HASH_LEN. */

>> +		return -EINVAL;

> 

> -ENOPKG might be better.  It's not that the string is invalid, it's just that

> it's unsupported at the moment.


Right, I'll switch to this with the next series.

> 

> David

>
Jarkko Sakkinen Dec. 4, 2020, 3:38 p.m. UTC | #11
On Fri, Dec 04, 2020 at 02:01:36PM +0000, David Howells wrote:
> Mickaël Salaün <mic@digikod.net> wrote:

> 

> > > What would be easiest way to smoke test the changes?

> > 

> > An easy way to test it is to enable the second trusted keyring to

> > dynamically load certificates in the kernel. Then we can create a hash

> > of a valid certificate (but not loaded yet) and sign it as explained in

> > tools/certs/print-cert-tbs-hash.sh (patch 9/9). Once this hash is loaded

> > in the kernel, loading the blacklisted certificate will be denied. We

> > can also test it with a PKCS#7 signature chain, either with the

> > blacklist keyring itself, or with a signed dm-verity image.

> 

> It might also be possible to use the pkcs#7 test key type

> (CONFIG_PKCS7_TEST_KEY) to aid in that.

> 

> David


Thanks, note taken.

/Jarkko
Mickaël Salaün Dec. 11, 2020, 6:35 p.m. UTC | #12
On 04/12/2020 15:09, David Howells wrote:
> Mickaël Salaün <mic@digikod.net> wrote:

> 

>> +	if (*desc)

>> +		/* The hash is greater than MAX_HASH_LEN. */

>> +		return -EINVAL;

> 

> -ENOPKG might be better.  It's not that the string is invalid, it's just that

> it's unsupported at the moment.


Indeed, I'll use that.

> 

> David

>