19 Mar, 2020

1 commit

  • …am_jr_enqueue function

    In commit 4d370a103695 ("crypto: caam - change return code in caam_jr_enqueue function"),
    the return code of caam_jr_enqueue function was changed
    from 0 to -EINPROGRESS, in case of success, -ENOSPC in case
    the CAAM is busy (has no space left in job ring queue),
    -EIO if it cannot map the caller's descriptor.

    Update the case for wait_for_completion in sk_job_submit
    based on the new return code from caam_jr_enqueue function.

    Fixes: 4d370a103695 ("crypto: caam - change return code in caam_jr_enqueue function")
    Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
    Reviewed-by: Horia Geantă <horia.geanta@nxp.com>

    Iuliana Prodan
     

26 Feb, 2020

1 commit


25 Nov, 2019

2 commits


25 Sep, 2019

1 commit

  • Commit 0b6cf6b97b7e ("tpm: pass an array of tpm_extend_digest structures to
    tpm_pcr_extend()") modifies tpm_pcr_extend() to accept a digest for each
    PCR bank. After modification, tpm_pcr_extend() expects that digests are
    passed in the same order as the algorithms set in chip->allocated_banks.

    This patch fixes two issues introduced in the last iterations of the patch
    set: missing initialization of the TPM algorithm ID in the tpm_digest
    structures passed to tpm_pcr_extend() by the trusted key module, and
    unreleased locks in the TPM driver due to returning from tpm_pcr_extend()
    without calling tpm_put_ops().

    Cc: stable@vger.kernel.org
    Fixes: 0b6cf6b97b7e ("tpm: pass an array of tpm_extend_digest structures to tpm_pcr_extend()")
    Signed-off-by: Roberto Sassu
    Suggested-by: Jarkko Sakkinen
    Reviewed-by: Jerry Snitselaar
    Reviewed-by: Jarkko Sakkinen
    Signed-off-by: Jarkko Sakkinen

    Roberto Sassu
     

06 Sep, 2019

1 commit

  • If a request_key authentication token key gets revoked, there's a window in
    which request_key_auth_describe() can see it with a NULL payload - but it
    makes no check for this and something like the following oops may occur:

    BUG: Kernel NULL pointer dereference at 0x00000038
    Faulting instruction address: 0xc0000000004ddf30
    Oops: Kernel access of bad area, sig: 11 [#1]
    ...
    NIP [...] request_key_auth_describe+0x90/0xd0
    LR [...] request_key_auth_describe+0x54/0xd0
    Call Trace:
    [...] request_key_auth_describe+0x54/0xd0 (unreliable)
    [...] proc_keys_show+0x308/0x4c0
    [...] seq_read+0x3d0/0x540
    [...] proc_reg_read+0x90/0x110
    [...] __vfs_read+0x3c/0x70
    [...] vfs_read+0xb4/0x1b0
    [...] ksys_read+0x7c/0x130
    [...] system_call+0x5c/0x70

    Fix this by checking for a NULL pointer when describing such a key.

    Also make the read routine check for a NULL pointer to be on the safe side.

    [DH: Modified to not take already-held rcu lock and modified to also check
    in the read routine]

    Fixes: 04c567d9313e ("[PATCH] Keys: Fix race between two instantiators of a key")
    Reported-by: Sachin Sant
    Signed-off-by: Hillf Danton
    Signed-off-by: David Howells
    Tested-by: Sachin Sant
    Signed-off-by: Linus Torvalds

    Hillf Danton
     

31 Aug, 2019

1 commit


14 Aug, 2019

1 commit

  • Commit c78719203fc6 ("KEYS: trusted: allow trusted.ko to initialize w/o a
    TPM") allows the trusted module to be loaded even if a TPM is not found, to
    avoid module dependency problems.

    However, trusted module initialization can still fail if the TPM is
    inactive or deactivated. tpm_get_random() returns an error.

    This patch removes the call to tpm_get_random() and instead extends the PCR
    specified by the user with zeros. The security of this alternative is
    equivalent to the previous one, as either option prevents with a PCR update
    unsealing and misuse of sealed data by a user space process.

    Even if a PCR is extended with zeros, instead of random data, it is still
    computationally infeasible to find a value as input for a new PCR extend
    operation, to obtain again the PCR value that would allow unsealing.

    Cc: stable@vger.kernel.org
    Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure...")
    Signed-off-by: Roberto Sassu
    Reviewed-by: Tyler Hicks
    Suggested-by: Mimi Zohar
    Reviewed-by: Jarkko Sakkinen
    Signed-off-by: Jarkko Sakkinen

    Roberto Sassu
     

19 Jul, 2019

1 commit

  • In the sysctl code the proc_dointvec_minmax() function is often used to
    validate the user supplied value between an allowed range. This
    function uses the extra1 and extra2 members from struct ctl_table as
    minimum and maximum allowed value.

    On sysctl handler declaration, in every source file there are some
    readonly variables containing just an integer which address is assigned
    to the extra1 and extra2 members, so the sysctl range is enforced.

    The special values 0, 1 and INT_MAX are very often used as range
    boundary, leading duplication of variables like zero=0, one=1,
    int_max=INT_MAX in different source files:

    $ git grep -E '\.extra[12].*&(zero|one|int_max)' |wc -l
    248

    Add a const int array containing the most commonly used values, some
    macros to refer more easily to the correct array member, and use them
    instead of creating a local one for every object file.

    This is the bloat-o-meter output comparing the old and new binary
    compiled with the default Fedora config:

    # scripts/bloat-o-meter -d vmlinux.o.old vmlinux.o
    add/remove: 2/2 grow/shrink: 0/2 up/down: 24/-188 (-164)
    Data old new delta
    sysctl_vals - 12 +12
    __kstrtab_sysctl_vals - 12 +12
    max 14 10 -4
    int_max 16 - -16
    one 68 - -68
    zero 128 28 -100
    Total: Before=20583249, After=20583085, chg -0.00%

    [mcroce@redhat.com: tipc: remove two unused variables]
    Link: http://lkml.kernel.org/r/20190530091952.4108-1-mcroce@redhat.com
    [akpm@linux-foundation.org: fix net/ipv6/sysctl_net_ipv6.c]
    [arnd@arndb.de: proc/sysctl: make firmware loader table conditional]
    Link: http://lkml.kernel.org/r/20190617130014.1713870-1-arnd@arndb.de
    [akpm@linux-foundation.org: fix fs/eventpoll.c]
    Link: http://lkml.kernel.org/r/20190430180111.10688-1-mcroce@redhat.com
    Signed-off-by: Matteo Croce
    Signed-off-by: Arnd Bergmann
    Acked-by: Kees Cook
    Reviewed-by: Aaron Tomlin
    Cc: Matthew Wilcox
    Cc: Stephen Rothwell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matteo Croce
     

11 Jul, 2019

1 commit

  • …el/git/dhowells/linux-fs"

    This reverts merge 0f75ef6a9cff49ff612f7ce0578bced9d0b38325 (and thus
    effectively commits

    7a1ade847596 ("keys: Provide KEYCTL_GRANT_PERMISSION")
    2e12256b9a76 ("keys: Replace uid/gid/perm permissions checking with an ACL")

    that the merge brought in).

    It turns out that it breaks booting with an encrypted volume, and Eric
    biggers reports that it also breaks the fscrypt tests [1] and loading of
    in-kernel X.509 certificates [2].

    The root cause of all the breakage is likely the same, but David Howells
    is off email so rather than try to work it out it's getting reverted in
    order to not impact the rest of the merge window.

    [1] https://lore.kernel.org/lkml/20190710011559.GA7973@sol.localdomain/
    [2] https://lore.kernel.org/lkml/20190710013225.GB7973@sol.localdomain/

    Link: https://lore.kernel.org/lkml/CAHk-=wjxoeMJfeBahnWH=9zShKp2bsVy527vo3_y8HfOdhwAAw@mail.gmail.com/
    Reported-by: Eric Biggers <ebiggers@kernel.org>
    Cc: David Howells <dhowells@redhat.com>
    Cc: James Morris <jmorris@namei.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

    Linus Torvalds
     

09 Jul, 2019

4 commits

  • Pull keyring ACL support from David Howells:
    "This changes the permissions model used by keys and keyrings to be
    based on an internal ACL by the following means:

    - Replace the permissions mask internally with an ACL that contains a
    list of ACEs, each with a specific subject with a permissions mask.
    Potted default ACLs are available for new keys and keyrings.

    ACE subjects can be macroised to indicate the UID and GID specified
    on the key (which remain). Future commits will be able to add
    additional subject types, such as specific UIDs or domain
    tags/namespaces.

    Also split a number of permissions to give finer control. Examples
    include splitting the revocation permit from the change-attributes
    permit, thereby allowing someone to be granted permission to revoke
    a key without allowing them to change the owner; also the ability
    to join a keyring is split from the ability to link to it, thereby
    stopping a process accessing a keyring by joining it and thus
    acquiring use of possessor permits.

    - Provide a keyctl to allow the granting or denial of one or more
    permits to a specific subject. Direct access to the ACL is not
    granted, and the ACL cannot be viewed"

    * tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
    keys: Provide KEYCTL_GRANT_PERMISSION
    keys: Replace uid/gid/perm permissions checking with an ACL

    Linus Torvalds
     
  • …/git/dhowells/linux-fs

    Pull keyring namespacing from David Howells:
    "These patches help make keys and keyrings more namespace aware.

    Firstly some miscellaneous patches to make the process easier:

    - Simplify key index_key handling so that the word-sized chunks
    assoc_array requires don't have to be shifted about, making it
    easier to add more bits into the key.

    - Cache the hash value in the key so that we don't have to calculate
    on every key we examine during a search (it involves a bunch of
    multiplications).

    - Allow keying_search() to search non-recursively.

    Then the main patches:

    - Make it so that keyring names are per-user_namespace from the point
    of view of KEYCTL_JOIN_SESSION_KEYRING so that they're not
    accessible cross-user_namespace.

    keyctl_capabilities() shows KEYCTL_CAPS1_NS_KEYRING_NAME for this.

    - Move the user and user-session keyrings to the user_namespace
    rather than the user_struct. This prevents them propagating
    directly across user_namespaces boundaries (ie. the KEY_SPEC_*
    flags will only pick from the current user_namespace).

    - Make it possible to include the target namespace in which the key
    shall operate in the index_key. This will allow the possibility of
    multiple keys with the same description, but different target
    domains to be held in the same keyring.

    keyctl_capabilities() shows KEYCTL_CAPS1_NS_KEY_TAG for this.

    - Make it so that keys are implicitly invalidated by removal of a
    domain tag, causing them to be garbage collected.

    - Institute a network namespace domain tag that allows keys to be
    differentiated by the network namespace in which they operate. New
    keys that are of a type marked 'KEY_TYPE_NET_DOMAIN' are assigned
    the network domain in force when they are created.

    - Make it so that the desired network namespace can be handed down
    into the request_key() mechanism. This allows AFS, NFS, etc. to
    request keys specific to the network namespace of the superblock.

    This also means that the keys in the DNS record cache are
    thenceforth namespaced, provided network filesystems pass the
    appropriate network namespace down into dns_query().

    For DNS, AFS and NFS are good, whilst CIFS and Ceph are not. Other
    cache keyrings, such as idmapper keyrings, also need to set the
    domain tag - for which they need access to the network namespace of
    the superblock"

    * tag 'keys-namespace-20190627' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
    keys: Pass the network namespace into request_key mechanism
    keys: Network namespace domain tag
    keys: Garbage collect keys for which the domain has been removed
    keys: Include target namespace in match criteria
    keys: Move the user and user-session keyrings to the user_namespace
    keys: Namespace keyring names
    keys: Add a 'recurse' flag for keyring searches
    keys: Cache the hash value to avoid lots of recalculation
    keys: Simplify key description management

    Linus Torvalds
     
  • Pull request_key improvements from David Howells:
    "These are all request_key()-related, including a fix and some improvements:

    - Fix the lack of a Link permission check on a key found by
    request_key(), thereby enabling request_key() to link keys that
    don't grant this permission to the target keyring (which must still
    grant Write permission).

    Note that the key must be in the caller's keyrings already to be
    found.

    - Invalidate used request_key authentication keys rather than
    revoking them, so that they get cleaned up immediately rather than
    hanging around till the expiry time is passed.

    - Move the RCU locks outwards from the keyring search functions so
    that a request_key_rcu() can be provided. This can be called in RCU
    mode, so it can't sleep and can't upcall - but it can be called
    from LOOKUP_RCU pathwalk mode.

    - Cache the latest positive result of request_key*() temporarily in
    task_struct so that filesystems that make a lot of request_key()
    calls during pathwalk can take advantage of it to avoid having to
    redo the searching. This requires CONFIG_KEYS_REQUEST_CACHE=y.

    It is assumed that the key just found is likely to be used multiple
    times in each step in an RCU pathwalk, and is likely to be reused
    for the next step too.

    Note that the cleanup of the cache is done on TIF_NOTIFY_RESUME,
    just before userspace resumes, and on exit"

    * tag 'keys-request-20190626' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
    keys: Kill off request_key_async{,_with_auxdata}
    keys: Cache result of request_key*() temporarily in task_struct
    keys: Provide request_key_rcu()
    keys: Move the RCU locks outwards from the keyring search functions
    keys: Invalidate used request_key authentication keys
    keys: Fix request_key() lack of Link perm check on found key

    Linus Torvalds
     
  • Pull misc keyring updates from David Howells:
    "These are some miscellaneous keyrings fixes and improvements:

    - Fix a bunch of warnings from sparse, including missing RCU bits and
    kdoc-function argument mismatches

    - Implement a keyctl to allow a key to be moved from one keyring to
    another, with the option of prohibiting key replacement in the
    destination keyring.

    - Grant Link permission to possessors of request_key_auth tokens so
    that upcall servicing daemons can more easily arrange things such
    that only the necessary auth key is passed to the actual service
    program, and not all the auth keys a daemon might possesss.

    - Improvement in lookup_user_key().

    - Implement a keyctl to allow keyrings subsystem capabilities to be
    queried.

    The keyutils next branch has commits to make available, document and
    test the move-key and capabilities code:

    https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/keyutils.git/log

    They're currently on the 'next' branch"

    * tag 'keys-misc-20190619' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
    keys: Add capability-checking keyctl function
    keys: Reuse keyring_index_key::desc_len in lookup_user_key()
    keys: Grant Link permission to possessers of request_key auth keys
    keys: Add a keyctl to move a key between keyrings
    keys: Hoist locking out of __key_link_begin()
    keys: Break bits out of key_unlink()
    keys: Change keyring_serialise_link_sem to a mutex
    keys: sparse: Fix kdoc mismatches
    keys: sparse: Fix incorrect RCU accesses
    keys: sparse: Fix key_fs[ug]id_changed()

    Linus Torvalds
     

03 Jul, 2019

1 commit

  • Provide a keyctl() operation to grant/remove permissions. The grant
    operation, wrapped by libkeyutils, looks like:

    int ret = keyctl_grant_permission(key_serial_t key,
    enum key_ace_subject_type type,
    unsigned int subject,
    unsigned int perm);

    Where key is the key to be modified, type and subject represent the subject
    to which permission is to be granted (or removed) and perm is the set of
    permissions to be granted. 0 is returned on success. SET_SECURITY
    permission is required for this.

    The subject type currently must be KEY_ACE_SUBJ_STANDARD for the moment
    (other subject types will come along later).

    For subject type KEY_ACE_SUBJ_STANDARD, the following subject values are
    available:

    KEY_ACE_POSSESSOR The possessor of the key
    KEY_ACE_OWNER The owner of the key
    KEY_ACE_GROUP The key's group
    KEY_ACE_EVERYONE Everyone

    perm lists the permissions to be granted:

    KEY_ACE_VIEW Can view the key metadata
    KEY_ACE_READ Can read the key content
    KEY_ACE_WRITE Can update/modify the key content
    KEY_ACE_SEARCH Can find the key by searching/requesting
    KEY_ACE_LINK Can make a link to the key
    KEY_ACE_SET_SECURITY Can set security
    KEY_ACE_INVAL Can invalidate
    KEY_ACE_REVOKE Can revoke
    KEY_ACE_JOIN Can join this keyring
    KEY_ACE_CLEAR Can clear this keyring

    If an ACE already exists for the subject, then the permissions mask will be
    overwritten; if perm is 0, it will be deleted.

    Currently, the internal ACL is limited to a maximum of 16 entries.

    For example:

    int ret = keyctl_grant_permission(key,
    KEY_ACE_SUBJ_STANDARD,
    KEY_ACE_OWNER,
    KEY_ACE_VIEW | KEY_ACE_READ);

    Signed-off-by: David Howells

    David Howells
     

28 Jun, 2019

2 commits

  • 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: David Howells

    David Howells
     
  • Create a request_key_net() function and use it to pass the network
    namespace domain tag into DNS revolver keys and rxrpc/AFS keys so that keys
    for different domains can coexist in the same keyring.

    Signed-off-by: David Howells
    cc: netdev@vger.kernel.org
    cc: linux-nfs@vger.kernel.org
    cc: linux-cifs@vger.kernel.org
    cc: linux-afs@lists.infradead.org

    David Howells
     

27 Jun, 2019

9 commits

  • Create key domain tags for network namespaces and make it possible to
    automatically tag keys that are used by networked services (e.g. AF_RXRPC,
    AFS, DNS) with the default network namespace if not set by the caller.

    This allows keys with the same description but in different namespaces to
    coexist within a keyring.

    Signed-off-by: David Howells
    cc: netdev@vger.kernel.org
    cc: linux-nfs@vger.kernel.org
    cc: linux-cifs@vger.kernel.org
    cc: linux-afs@lists.infradead.org

    David Howells
     
  • If a key operation domain (such as a network namespace) has been removed
    then attempt to garbage collect all the keys that use it.

    Signed-off-by: David Howells

    David Howells
     
  • Currently a key has a standard matching criteria of { type, description }
    and this is used to only allow keys with unique criteria in a keyring.
    This means, however, that you cannot have keys with the same type and
    description but a different target namespace in the same keyring.

    This is a potential problem for a containerised environment where, say, a
    container is made up of some parts of its mount space involving netfs
    superblocks from two different network namespaces.

    This is also a problem for shared system management keyrings such as the
    DNS records keyring or the NFS idmapper keyring that might contain keys
    from different network namespaces.

    Fix this by including a namespace component in a key's matching criteria.
    Keyring types are marked to indicate which, if any, namespace is relevant
    to keys of that type, and that namespace is set when the key is created
    from the current task's namespace set.

    The capability bit KEYCTL_CAPS1_NS_KEY_TAG is set if the kernel is
    employing this feature.

    Signed-off-by: David Howells

    David Howells
     
  • Move the user and user-session keyrings to the user_namespace struct rather
    than pinning them from the user_struct struct. This prevents these
    keyrings from propagating across user-namespaces boundaries with regard to
    the KEY_SPEC_* flags, thereby making them more useful in a containerised
    environment.

    The issue is that a single user_struct may be represent UIDs in several
    different namespaces.

    The way the patch does this is by attaching a 'register keyring' in each
    user_namespace and then sticking the user and user-session keyrings into
    that. It can then be searched to retrieve them.

    Signed-off-by: David Howells
    cc: Jann Horn

    David Howells
     
  • Keyring names are held in a single global list that any process can pick
    from by means of keyctl_join_session_keyring (provided the keyring grants
    Search permission). This isn't very container friendly, however.

    Make the following changes:

    (1) Make default session, process and thread keyring names begin with a
    '.' instead of '_'.

    (2) Keyrings whose names begin with a '.' aren't added to the list. Such
    keyrings are system specials.

    (3) Replace the global list with per-user_namespace lists. A keyring adds
    its name to the list for the user_namespace that it is currently in.

    (4) When a user_namespace is deleted, it just removes itself from the
    keyring name list.

    The global keyring_name_lock is retained for accessing the name lists.
    This allows (4) to work.

    This can be tested by:

    # keyctl newring foo @s
    995906392
    # unshare -U
    $ keyctl show
    ...
    995906392 --alswrv 65534 65534 \_ keyring: foo
    ...
    $ keyctl session foo
    Joined session keyring: 935622349

    As can be seen, a new session keyring was created.

    The capability bit KEYCTL_CAPS1_NS_KEYRING_NAME is set if the kernel is
    employing this feature.

    Signed-off-by: David Howells
    cc: Eric W. Biederman

    David Howells
     
  • Add a 'recurse' flag for keyring searches so that the flag can be omitted
    and recursion disabled, thereby allowing just the nominated keyring to be
    searched and none of the children.

    Signed-off-by: David Howells

    David Howells
     
  • Cache the hash of the key's type and description in the index key so that
    we're not recalculating it every time we look at a key during a search.
    The hash function does a bunch of multiplications, so evading those is
    probably worthwhile - especially as this is done for every key examined
    during a search.

    This also allows the methods used by assoc_array to get chunks of index-key
    to be simplified.

    Signed-off-by: David Howells

    David Howells
     
  • Simplify key description management by cramming the word containing the
    length with the first few chars of the description also. This simplifies
    the code that generates the index-key used by assoc_array. It should speed
    up key searching a bit too.

    Signed-off-by: David Howells

    David Howells
     
  • Kill off request_key_async{,_with_auxdata}() as they're not currently used.

    Signed-off-by: David Howells

    David Howells
     

19 Jun, 2019

6 commits

  • If a filesystem uses keys to hold authentication tokens, then it needs a
    token for each VFS operation that might perform an authentication check -
    either by passing it to the server, or using to perform a check based on
    authentication data cached locally.

    For open files this isn't a problem, since the key should be cached in the
    file struct since it represents the subject performing operations on that
    file descriptor.

    During pathwalk, however, there isn't anywhere to cache the key, except
    perhaps in the nameidata struct - but that isn't exposed to the
    filesystems. Further, a pathwalk can incur a lot of operations, calling
    one or more of the following, for instance:

    ->lookup()
    ->permission()
    ->d_revalidate()
    ->d_automount()
    ->get_acl()
    ->getxattr()

    on each dentry/inode it encounters - and each one may need to call
    request_key(). And then, at the end of pathwalk, it will call the actual
    operation:

    ->mkdir()
    ->mknod()
    ->getattr()
    ->open()
    ...

    which may need to go and get the token again.

    However, it is very likely that all of the operations on a single
    dentry/inode - and quite possibly a sequence of them - will all want to use
    the same authentication token, which suggests that caching it would be a
    good idea.

    To this end:

    (1) Make it so that a positive result of request_key() and co. that didn't
    require upcalling to userspace is cached temporarily in task_struct.

    (2) The cache is 1 deep, so a new result displaces the old one.

    (3) The key is released by exit and by notify-resume.

    (4) The cache is cleared in a newly forked process.

    Signed-off-by: David Howells

    David Howells
     
  • Provide a request_key_rcu() function that can be used to request a key
    under RCU conditions. It can only search and check permissions; it cannot
    allocate a new key, upcall or wait for an upcall to complete. It may
    return a partially constructed key.

    Signed-off-by: David Howells

    David Howells
     
  • Move the RCU locks outwards from the keyring search functions so that it
    will become possible to provide an RCU-capable partial request_key()
    function in a later commit.

    Signed-off-by: David Howells

    David Howells
     
  • Invalidate used request_key authentication keys rather than revoking them
    so that they get cleaned up immediately rather than potentially hanging
    around. There doesn't seem any need to keep the revoked keys around.

    Signed-off-by: David Howells

    David Howells
     
  • The request_key() syscall allows a process to gain access to the 'possessor'
    permits of any key that grants it Search permission by virtue of request_key()
    not checking whether a key it finds grants Link permission to the caller.

    Signed-off-by: David Howells

    David Howells
     
  • Add a keyctl function that requests a set of capability bits to find out
    what features are supported.

    Signed-off-by: David Howells

    David Howells
     

05 Jun, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation version 2 of the license

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 315 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Reviewed-by: Armijn Hemel
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190531190115.503150771@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

31 May, 2019

5 commits

  • When lookup_user_key() checks whether the key is possessed, it should
    use the key's existing index_key including the 'desc_len' field, rather
    than recomputing the 'desc_len'. This doesn't change the behavior; this
    way is just simpler and faster.

    Signed-off-by: Eric Biggers
    Signed-off-by: David Howells
    Reviewed-by: James Morris

    Eric Biggers
     
  • Grant Link permission to the possessers of request_key authentication keys,
    thereby allowing a daemon that is servicing upcalls to arrange things such
    that only the necessary auth key is passed to the actual service program
    and not all the daemon's pending auth keys.

    Signed-off-by: David Howells
    Reviewed-by: James Morris

    David Howells
     
  • Add a keyctl to atomically move a link to a key from one keyring to
    another. The key must exist in "from" keyring and a flag can be given to
    cause the operation to fail if there's a matching key already in the "to"
    keyring.

    This can be done with:

    keyctl(KEYCTL_MOVE,
    key_serial_t key,
    key_serial_t from_keyring,
    key_serial_t to_keyring,
    unsigned int flags);

    The key being moved must grant Link permission and both keyrings must grant
    Write permission.

    flags should be 0 or KEYCTL_MOVE_EXCL, with the latter preventing
    displacement of a matching key from the "to" keyring.

    Signed-off-by: David Howells

    David Howells
     
  • Hoist the locking of out of __key_link_begin() and into its callers. This
    is necessary to allow the upcoming key_move() operation to correctly order
    taking of the source keyring semaphore, the destination keyring semaphore
    and the keyring serialisation lock.

    Signed-off-by: David Howells

    David Howells
     
  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 3029 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

30 May, 2019

2 commits