Forum | Documentation | Website | Blog

Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Mar 08, 2022
  3. Mar 02, 2022
  5. Jan 22, 2022
  7. Jan 08, 2022
    • Masahiro Yamada's avatar
      certs: move scripts/extract-cert to certs/ · 340a0253
      Masahiro Yamada authored 
      
extract-cert is only used in certs/Makefile.

Move it there and build extract-cert on demand.

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      340a0253
    • Masahiro Yamada's avatar
      kbuild: do not quote string values in include/config/auto.conf · 129ab0d2
      Masahiro Yamada authored 
      
The previous commit fixed up all shell scripts to not include
include/config/auto.conf.

Now that include/config/auto.conf is only included by Makefiles,
we can change it into a more Make-friendly form.

Previously, Kconfig output string values enclosed with double-quotes
(both in the .config and include/config/auto.conf):

    CONFIG_X="foo bar"

Unlike shell, Make handles double-quotes (and single-quotes as well)
verbatim. We must rip them off when used.

There are some patterns:

  [1] $(patsubst "%",%,$(CONFIG_X))
  [2] $(CONFIG_X:"%"=%)
  [3] $(subst ",,$(CONFIG_X))
  [4] $(shell echo $(CONFIG_X))

These are not only ugly, but also fragile.

[1] and [2] do not work if the value contains spaces, like
   CONFIG_X=" foo bar "

[3] does not work correctly if the value contains double-quotes like
   CONFIG_X="foo\"bar"

[4] seems to work better, but has a cost of forking a process.

Anyway, quoted strings were always PITA for our Makefiles.

This commit changes Kconfig to stop quoting in include/config/auto.conf.

These are the string type symbols referenced in Makefiles or scripts:

    ACPI_CUSTOM_DSDT_FILE
    ARC_BUILTIN_DTB_NAME
    ARC_TUNE_MCPU
    BUILTIN_DTB_SOURCE
    CC_IMPLICIT_FALLTHROUGH
    CC_VERSION_TEXT
    CFG80211_EXTRA_REGDB_KEYDIR
    EXTRA_FIRMWARE
    EXTRA_FIRMWARE_DIR
    EXTRA_TARGETS
    H8300_BUILTIN_DTB
    INITRAMFS_SOURCE
    LOCALVERSION
    MODULE_SIG_HASH
    MODULE_SIG_KEY
    NDS32_BUILTIN_DTB
    NIOS2_DTB_SOURCE
    OPENRISC_BUILTIN_DTB
    SOC_CANAAN_K210_DTB_SOURCE
    SYSTEM_BLACKLIST_HASH_LIST
    SYSTEM_REVOCATION_KEYS
    SYSTEM_TRUSTED_KEYS
    TARGET_CPU
    UNUSED_KSYMS_WHITELIST
    XILINX_MICROBLAZE0_FAMILY
    XILINX_MICROBLAZE0_HW_VER
    XTENSA_VARIANT_NAME

I checked them one by one, and fixed up the code where necessary.

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      129ab0d2
    • Masahiro Yamada's avatar
      certs: simplify $(srctree)/ handling and remove config_filename macro · b8c96a6b
      Masahiro Yamada authored 
      
The complex macro, config_filename, was introduced to do:

 [1] drop double-quotes from the string value
 [2] add $(srctree)/ prefix in case the file is not found in $(objtree)
 [3] escape spaces and more

[1] will be more generally handled by Kconfig later.

As for [2], Kbuild uses VPATH to search for files in $(objtree),
$(srctree) in this order. GNU Make can natively handle it.

As for [3], converting $(space) to $(space_escape) back and forth looks
questionable to me. It is well-known that GNU Make cannot handle file
paths with spaces in the first place.

Instead of using the complex macro, use $< so it will be expanded to
the file path of the key.

Remove config_filename, finally.

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      b8c96a6b
    • Masahiro Yamada's avatar
      certs: remove misleading comments about GCC PR · 5410f3e8
      Masahiro Yamada authored 
      
This dependency is necessary irrespective of the mentioned GCC PR
because the embedded certificates are build artifacts and must be
generated by extract_certs before *.S files are compiled.

The comment sounds like we are hoping to remove these dependencies
someday. No, we cannot remove them.

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      5410f3e8
    • Masahiro Yamada's avatar
      certs: refactor file cleaning · 5cca3606
      Masahiro Yamada authored 
      
'make clean' removes files listed in 'targets'. It is redundant to
specify both 'targets' and 'clean-files'.

Move 'targets' assignments out of the ifeq-conditionals so
scripts/Makefile.clean can see them.

One effective change is that certs/certs/signing_key.x509 is now
deleted by 'make clean' instead of 'make mrproper. This certificate
is embedded in the kernel. It is not used in any way by external
module builds.

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      5cca3606
    • Masahiro Yamada's avatar
      certs: remove unneeded -I$(srctree) option for system_certificates.o · 3958f215
      Masahiro Yamada authored 
      
The .incbin directive in certs/system_certificates.S includes
certs/signing_key.x509 and certs/x509_certificate_list, both of which
are generated by extract_certs, i.e. exist in $(objtree).

This option -I$(srctree) is unneeded.

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      3958f215
    • Masahiro Yamada's avatar
      certs: unify duplicated cmd_extract_certs and improve the log · 1c4bd9f7
      Masahiro Yamada authored 
      
cmd_extract_certs is defined twice. Unify them.

The current log shows the input file $(2), which might be empty.
You cannot know what is being created from the log, "EXTRACT_CERTS".

Change the log to show the output file with better alignment.

[Before]

  EXTRACT_CERTS   certs/signing_key.pem
  CC      certs/system_keyring.o
  EXTRACT_CERTS
  AS      certs/system_certificates.o
  CC      certs/common.o
  CC      certs/blacklist.o
  EXTRACT_CERTS
  AS      certs/revocation_certificates.o

[After]

  CERT    certs/signing_key.x509
  CC      certs/system_keyring.o
  CERT    certs/x509_certificate_list
  AS      certs/system_certificates.o
  CC      certs/common.o
  CC      certs/blacklist.o
  CERT    certs/x509_revocation_list
  AS      certs/revocation_certificates.o

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      1c4bd9f7
    • Masahiro Yamada's avatar
      certs: use $< and $@ to simplify the key generation rule · c537e4d0
      Masahiro Yamada authored 
      
Do not repeat $(obj)/x509.genkey or $(obj)/signing_key.pem

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      c537e4d0
  9. Dec 11, 2021
  11. Aug 23, 2021
  13. May 01, 2021
  15. Apr 26, 2021
  17. Apr 09, 2021
  19. Mar 11, 2021
  21. Jan 21, 2021
    • Mickaël Salaün's avatar
      certs: Replace K{U,G}IDT_INIT() with GLOBAL_ROOT_{U,G}ID · a6cb0ab7
      Mickaël Salaün authored 
      
Align with the new macros and add appropriate include files.

Signed-off-by: default avatarMickaël Salaün <mic@linux.microsoft.com>
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>
      a6cb0ab7
    • David Howells's avatar
      certs: Fix blacklist flag type confusion · 4993e1f9
      David Howells authored 
      KEY_FLAG_KEEP is not meant to be passed to keyring_alloc() or key_alloc(),
as these only take KEY_ALLOC_* flags.  KEY_FLAG_KEEP has the same value as
KEY_ALLOC_BYPASS_RESTRICTION, but fortunately only key_create_or_update()
uses it.  LSMs using the key_alloc hook don't check that flag.

KEY_FLAG_KEEP is then ignored but fortunately (again) the root user cannot
write to the blacklist keyring, so it is not possible to remove a key/hash
from it.

Fix this by adding a KEY_ALLOC_SET_KEEP flag that tells key_alloc() to set
KEY_FLAG_KEEP on the new key.  blacklist_init() can then, correctly, pass
this to keyring_alloc().

We can also use this in ima_mok_init() rather than setting the flag
manually.

Note that this doesn't fix an observable bug with the current
implementation but it is required to allow addition of new hashes to the
blacklist in the future without making it possible for them to be removed.

Fixes: 734114f8

 ("KEYS: Add a system blacklist keyring")
Reported-by: default avatarMickaël Salaün <mic@linux.microsoft.com>
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
cc: Mickaël Salaün <mic@linux.microsoft.com>
cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: David Woodhouse <dwmw2@infradead.org>
      4993e1f9
    • Mickaël Salaün's avatar
      certs: Fix blacklisted hexadecimal hash string check · 84ffbefd
      Mickaël Salaün authored 
      
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.

Signed-off-by: default avatarMickaël Salaün <mic@linux.microsoft.com>
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
Reviewed-by: default avatarBen Boeckel <mathstuf@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
      84ffbefd
    • Alex Shi's avatar
      certs/blacklist: fix kernel doc interface issue · 0b2d443b
      Alex Shi authored 
      
certs/blacklist.c:84: warning: Function parameter or member 'hash' not
described in 'mark_hash_blacklisted'

Signed-off-by: default avatarAlex Shi <alex.shi@linux.alibaba.com>
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
Reviewed-by: default avatarBen Boeckel <mathstuf@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: keyrings@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
      0b2d443b
  23. Mar 25, 2020
  25. Nov 11, 2019
  27. Aug 05, 2019
  29. Jul 10, 2019
  31. Jun 27, 2019
    • David Howells's avatar
      keys: Replace uid/gid/perm permissions checking with an ACL · 2e12256b
      David Howells authored 
      
Replace the uid/gid/perm permissions checking on a key with an ACL to allow
the SETATTR and SEARCH permissions to be split.  This will also allow a
greater range of subjects to represented.

============
WHY DO THIS?
============

The problem is that SETATTR and SEARCH cover a slew of actions, not all of
which should be grouped together.

For SETATTR, this includes actions that are about controlling access to a
key:

 (1) Changing a key's ownership.

 (2) Changing a key's security information.

 (3) Setting a keyring's restriction.

And actions that are about managing a key's lifetime:

 (4) Setting an expiry time.

 (5) Revoking a key.

and (proposed) managing a key as part of a cache:

 (6) Invalidating a key.

Managing a key's lifetime doesn't really have anything to do with
controlling access to that key.

Expiry time is awkward since it's more about the lifetime of the content
and so, in some ways goes better with WRITE permission.  It can, however,
be set unconditionally by a process with an appropriate authorisation token
for instantiating a key, and can also be set by the key type driver when a
key is instantiated, so lumping it with the access-controlling actions is
probably okay.

As for SEARCH permission, that currently covers:

 (1) Finding keys in a keyring tree during a search.

 (2) Permitting keyrings to be joined.

 (3) Invalidation.

But these don't really belong together either, since these actions really
need to be controlled separately.

Finally, there are number of special cases to do with granting the
administrator special rights to invalidate or clear keys that I would like
to handle with the ACL rather than key flags and special checks.


===============
WHAT IS CHANGED
===============

The SETATTR permission is split to create two new permissions:

 (1) SET_SECURITY - which allows the key's owner, group and ACL to be
     changed and a restriction to be placed on a keyring.

 (2) REVOKE - which allows a key to be revoked.

The SEARCH permission is split to create:

 (1) SEARCH - which allows a keyring to be search and a key to be found.

 (2) JOIN - which allows a keyring to be joined as a session keyring.

 (3) INVAL - which allows a key to be invalidated.

The WRITE permission is also split to create:

 (1) WRITE - which allows a key's content to be altered and links to be
     added, removed and replaced in a keyring.

 (2) CLEAR - which allows a keyring to be cleared completely.  This is
     split out to make it possible to give just this to an administrator.

 (3) REVOKE - see above.


Keys acquire ACLs which consist of a series of ACEs, and all that apply are
unioned together.  An ACE specifies a subject, such as:

 (*) Possessor - permitted to anyone who 'possesses' a key
 (*) Owner - permitted to the key owner
 (*) Group - permitted to the key group
 (*) Everyone - permitted to everyone

Note that 'Other' has been replaced with 'Everyone' on the assumption that
you wouldn't grant a permit to 'Other' that you wouldn't also grant to
everyone else.

Further subjects may be made available by later patches.

The ACE also specifies a permissions mask.  The set of permissions is now:

	VIEW		Can view the key metadata
	READ		Can read the key content
	WRITE		Can update/modify the key content
	SEARCH		Can find the key by searching/requesting
	LINK		Can make a link to the key
	SET_SECURITY	Can change owner, ACL, expiry
	INVAL		Can invalidate
	REVOKE		Can revoke
	JOIN		Can join this keyring
	CLEAR		Can clear this keyring


The KEYCTL_SETPERM function is then deprecated.

The KEYCTL_SET_TIMEOUT function then is permitted if SET_SECURITY is set,
or if the caller has a valid instantiation auth token.

The KEYCTL_INVALIDATE function then requires INVAL.

The KEYCTL_REVOKE function then requires REVOKE.

The KEYCTL_JOIN_SESSION_KEYRING function then requires JOIN to join an
existing keyring.

The JOIN permission is enabled by default for session keyrings and manually
created keyrings only.


======================
BACKWARD COMPATIBILITY
======================

To maintain backward compatibility, KEYCTL_SETPERM will translate the
permissions mask it is given into a new ACL for a key - unless
KEYCTL_SET_ACL has been called on that key, in which case an error will be
returned.

It will convert possessor, owner, group and other permissions into separate
ACEs, if each portion of the mask is non-zero.

SETATTR permission turns on all of INVAL, REVOKE and SET_SECURITY.  WRITE
permission turns on WRITE, REVOKE and, if a keyring, CLEAR.  JOIN is turned
on if a keyring is being altered.

The KEYCTL_DESCRIBE function translates the ACL back into a permissions
mask to return depending on possessor, owner, group and everyone ACEs.

It will make the following mappings:

 (1) INVAL, JOIN -> SEARCH

 (2) SET_SECURITY -> SETATTR

 (3) REVOKE -> WRITE if SETATTR isn't already set

 (4) CLEAR -> WRITE

Note that the value subsequently returned by KEYCTL_DESCRIBE may not match
the value set with KEYCTL_SETATTR.


=======
TESTING
=======

This passes the keyutils testsuite for all but a couple of tests:

 (1) tests/keyctl/dh_compute/badargs: The first wrong-key-type test now
     returns EOPNOTSUPP rather than ENOKEY as READ permission isn't removed
     if the type doesn't have ->read().  You still can't actually read the
     key.

 (2) tests/keyctl/permitting/valid: The view-other-permissions test doesn't
     work as Other has been replaced with Everyone in the ACL.

Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      2e12256b

Open hardware computers for makers, educators and professionals