Skip to content
Snippets Groups Projects
  1. Jun 21, 2022
  2. May 23, 2022
  3. Mar 11, 2021
  4. 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
  5. Nov 12, 2019
  6. Jul 11, 2019
  7. 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
  8. Jun 26, 2019
  9. May 24, 2019
  10. May 09, 2017
  11. Apr 03, 2017
    • David Howells's avatar
      KEYS: Add a system blacklist keyring · 734114f8
      David Howells authored
      
      Add the following:
      
       (1) A new system keyring that is used to store information about
           blacklisted certificates and signatures.
      
       (2) A new key type (called 'blacklist') that is used to store a
           blacklisted hash in its description as a hex string.  The key accepts
           no payload.
      
       (3) The ability to configure a list of blacklisted hashes into the kernel
           at build time.  This is done by setting
           CONFIG_SYSTEM_BLACKLIST_HASH_LIST to the filename of a list of hashes
           that are in the form:
      
      	"<hash>", "<hash>", ..., "<hash>"
      
           where each <hash> is a hex string representation of the hash and must
           include all necessary leading zeros to pad the hash to the right size.
      
      The above are enabled with CONFIG_SYSTEM_BLACKLIST_KEYRING.
      
      Once the kernel is booted, the blacklist keyring can be listed:
      
      	root@andromeda ~]# keyctl show %:.blacklist
      	Keyring
      	 723359729 ---lswrv      0     0  keyring: .blacklist
      	 676257228 ---lswrv      0     0   \_ blacklist: 123412341234c55c1dcc601ab8e172917706aa32fb5eaf826813547fdf02dd46
      
      The blacklist cannot currently be modified by userspace, but it will be
      possible to load it, for example, from the UEFI blacklist database.
      
      A later commit will make it possible to load blacklisted asymmetric keys in
      here too.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      734114f8
Loading