27 Oct, 2016

3 commits

  • Since BIG_KEYS can't be compiled as module it requires one of the "stdrng"
    providers to be compiled into kernel. Otherwise big_key_crypto_init() fails
    on crypto_alloc_rng step and next dereference of big_key_skcipher (e.g. in
    big_key_preparse()) results in a NULL pointer dereference.

    Fixes: 13100a72f40f5748a04017e0ab3df4cf27c809ef ('Security: Keys: Big keys stored encrypted')
    Signed-off-by: Artem Savkov
    Signed-off-by: David Howells
    cc: Stephan Mueller
    cc: Kirill Marinushkin
    cc: stable@vger.kernel.org
    Signed-off-by: James Morris

    Artem Savkov
     
  • big_key has two separate initialisation functions, one that registers the
    key type and one that registers the crypto. If the key type fails to
    register, there's no problem if the crypto registers successfully because
    there's no way to reach the crypto except through the key type.

    However, if the key type registers successfully but the crypto does not,
    big_key_rng and big_key_blkcipher may end up set to NULL - but the code
    neither checks for this nor unregisters the big key key type.

    Furthermore, since the key type is registered before the crypto, it is
    theoretically possible for the kernel to try adding a big_key before the
    crypto is set up, leading to the same effect.

    Fix this by merging big_key_crypto_init() and big_key_init() and calling
    the resulting function late. If they're going to be encrypted, we
    shouldn't be creating big_keys before we have the facilities to do the
    encryption available. The key type registration is also moved after the
    crypto initialisation.

    The fix also includes message printing on failure.

    If the big_key type isn't correctly set up, simply doing:

    dd if=/dev/zero bs=4096 count=1 | keyctl padd big_key a @s

    ought to cause an oops.

    Fixes: 13100a72f40f5748a04017e0ab3df4cf27c809ef ('Security: Keys: Big keys stored encrypted')
    Signed-off-by: David Howells
    cc: Peter Hlavaty
    cc: Kirill Marinushkin
    cc: Artem Savkov
    cc: stable@vger.kernel.org
    Signed-off-by: James Morris

    David Howells
     
  • This fixes CVE-2016-7042.

    Fix a short sprintf buffer in proc_keys_show(). If the gcc stack protector
    is turned on, this can cause a panic due to stack corruption.

    The problem is that xbuf[] is not big enough to hold a 64-bit timeout
    rendered as weeks:

    (gdb) p 0xffffffffffffffffULL/(60*60*24*7)
    $2 = 30500568904943

    That's 14 chars plus NUL, not 11 chars plus NUL.

    Expand the buffer to 16 chars.

    I think the unpatched code apparently works if the stack-protector is not
    enabled because on a 32-bit machine the buffer won't be overflowed and on a
    64-bit machine there's a 64-bit aligned pointer at one side and an int that
    isn't checked again on the other side.

    The panic incurred looks something like:

    Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81352ebe
    CPU: 0 PID: 1692 Comm: reproducer Not tainted 4.7.2-201.fc24.x86_64 #1
    Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
    0000000000000086 00000000fbbd2679 ffff8800a044bc00 ffffffff813d941f
    ffffffff81a28d58 ffff8800a044bc98 ffff8800a044bc88 ffffffff811b2cb6
    ffff880000000010 ffff8800a044bc98 ffff8800a044bc30 00000000fbbd2679
    Call Trace:
    [] dump_stack+0x63/0x84
    [] panic+0xde/0x22a
    [] ? proc_keys_show+0x3ce/0x3d0
    [] __stack_chk_fail+0x19/0x30
    [] proc_keys_show+0x3ce/0x3d0
    [] ? key_validate+0x50/0x50
    [] ? key_default_cmp+0x20/0x20
    [] seq_read+0x2cc/0x390
    [] proc_reg_read+0x42/0x70
    [] __vfs_read+0x37/0x150
    [] ? security_file_permission+0xa0/0xc0
    [] vfs_read+0x96/0x130
    [] SyS_read+0x55/0xc0
    [] entry_SYSCALL_64_fastpath+0x1a/0xa4

    Reported-by: Ondrej Kozina
    Signed-off-by: David Howells
    Tested-by: Ondrej Kozina
    cc: stable@vger.kernel.org
    Signed-off-by: James Morris

    David Howells
     

22 Sep, 2016

1 commit


30 Jul, 2016

1 commit

  • Pull security subsystem updates from James Morris:
    "Highlights:

    - TPM core and driver updates/fixes
    - IPv6 security labeling (CALIPSO)
    - Lots of Apparmor fixes
    - Seccomp: remove 2-phase API, close hole where ptrace can change
    syscall #"

    * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (156 commits)
    apparmor: fix SECURITY_APPARMOR_HASH_DEFAULT parameter handling
    tpm: Add TPM 2.0 support to the Nuvoton i2c driver (NPCT6xx family)
    tpm: Factor out common startup code
    tpm: use devm_add_action_or_reset
    tpm2_i2c_nuvoton: add irq validity check
    tpm: read burstcount from TPM_STS in one 32-bit transaction
    tpm: fix byte-order for the value read by tpm2_get_tpm_pt
    tpm_tis_core: convert max timeouts from msec to jiffies
    apparmor: fix arg_size computation for when setprocattr is null terminated
    apparmor: fix oops, validate buffer size in apparmor_setprocattr()
    apparmor: do not expose kernel stack
    apparmor: fix module parameters can be changed after policy is locked
    apparmor: fix oops in profile_unpack() when policy_db is not present
    apparmor: don't check for vmalloc_addr if kvzalloc() failed
    apparmor: add missing id bounds check on dfa verification
    apparmor: allow SYS_CAP_RESOURCE to be sufficient to prlimit another task
    apparmor: use list_next_entry instead of list_entry_next
    apparmor: fix refcount race when finding a child profile
    apparmor: fix ref count leak when profile sha1 hash is read
    apparmor: check that xindex is in trans_table bounds
    ...

    Linus Torvalds
     

27 Jul, 2016

1 commit

  • Pull crypto updates from Herbert Xu:
    "Here is the crypto update for 4.8:

    API:
    - first part of skcipher low-level conversions
    - add KPP (Key-agreement Protocol Primitives) interface.

    Algorithms:
    - fix IPsec/cryptd reordering issues that affects aesni
    - RSA no longer does explicit leading zero removal
    - add SHA3
    - add DH
    - add ECDH
    - improve DRBG performance by not doing CTR by hand

    Drivers:
    - add x86 AVX2 multibuffer SHA256/512
    - add POWER8 optimised crc32c
    - add xts support to vmx
    - add DH support to qat
    - add RSA support to caam
    - add Layerscape support to caam
    - add SEC1 AEAD support to talitos
    - improve performance by chaining requests in marvell/cesa
    - add support for Araneus Alea I USB RNG
    - add support for Broadcom BCM5301 RNG
    - add support for Amlogic Meson RNG
    - add support Broadcom NSP SoC RNG"

    * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (180 commits)
    crypto: vmx - Fix aes_p8_xts_decrypt build failure
    crypto: vmx - Ignore generated files
    crypto: vmx - Adding support for XTS
    crypto: vmx - Adding asm subroutines for XTS
    crypto: skcipher - add comment for skcipher_alg->base
    crypto: testmgr - Print akcipher algorithm name
    crypto: marvell - Fix wrong flag used for GFP in mv_cesa_dma_add_iv_op
    crypto: nx - off by one bug in nx_of_update_msc()
    crypto: rsa-pkcs1pad - fix rsa-pkcs1pad request struct
    crypto: scatterwalk - Inline start/map/done
    crypto: scatterwalk - Remove unnecessary BUG in scatterwalk_start
    crypto: scatterwalk - Remove unnecessary advance in scatterwalk_pagedone
    crypto: scatterwalk - Fix test in scatterwalk_done
    crypto: api - Optimise away crypto_yield when hard preemption is on
    crypto: scatterwalk - add no-copy support to copychunks
    crypto: scatterwalk - Remove scatterwalk_bytes_sglen
    crypto: omap - Stop using crypto scatterwalk_bytes_sglen
    crypto: skcipher - Remove top-level givcipher interface
    crypto: user - Remove crypto_lookup_skcipher call
    crypto: cts - Convert to skcipher
    ...

    Linus Torvalds
     

24 Jun, 2016

1 commit


17 Jun, 2016

1 commit

  • If __key_link_begin() failed then "edit" would be uninitialized. I've
    added a check to fix that.

    This allows a random user to crash the kernel, though it's quite
    difficult to achieve. There are three ways it can be done as the user
    would have to cause an error to occur in __key_link():

    (1) Cause the kernel to run out of memory. In practice, this is difficult
    to achieve without ENOMEM cropping up elsewhere and aborting the
    attempt.

    (2) Revoke the destination keyring between the keyring ID being looked up
    and it being tested for revocation. In practice, this is difficult to
    time correctly because the KEYCTL_REJECT function can only be used
    from the request-key upcall process. Further, users can only make use
    of what's in /sbin/request-key.conf, though this does including a
    rejection debugging test - which means that the destination keyring
    has to be the caller's session keyring in practice.

    (3) Have just enough key quota available to create a key, a new session
    keyring for the upcall and a link in the session keyring, but not then
    sufficient quota to create a link in the nominated destination keyring
    so that it fails with EDQUOT.

    The bug can be triggered using option (3) above using something like the
    following:

    echo 80 >/proc/sys/kernel/keys/root_maxbytes
    keyctl request2 user debug:fred negate @t

    The above sets the quota to something much lower (80) to make the bug
    easier to trigger, but this is dependent on the system. Note also that
    the name of the keyring created contains a random number that may be
    between 1 and 10 characters in size, so may throw the test off by
    changing the amount of quota used.

    Assuming the failure occurs, something like the following will be seen:

    kfree_debugcheck: out of range ptr 6b6b6b6b6b6b6b68h
    ------------[ cut here ]------------
    kernel BUG at ../mm/slab.c:2821!
    ...
    RIP: 0010:[] kfree_debugcheck+0x20/0x25
    RSP: 0018:ffff8804014a7de8 EFLAGS: 00010092
    RAX: 0000000000000034 RBX: 6b6b6b6b6b6b6b68 RCX: 0000000000000000
    RDX: 0000000000040001 RSI: 00000000000000f6 RDI: 0000000000000300
    RBP: ffff8804014a7df0 R08: 0000000000000001 R09: 0000000000000000
    R10: ffff8804014a7e68 R11: 0000000000000054 R12: 0000000000000202
    R13: ffffffff81318a66 R14: 0000000000000000 R15: 0000000000000001
    ...
    Call Trace:
    kfree+0xde/0x1bc
    assoc_array_cancel_edit+0x1f/0x36
    __key_link_end+0x55/0x63
    key_reject_and_link+0x124/0x155
    keyctl_reject_key+0xb6/0xe0
    keyctl_negate_key+0x10/0x12
    SyS_keyctl+0x9f/0xe7
    do_syscall_64+0x63/0x13a
    entry_SYSCALL64_slow_path+0x25/0x25

    Fixes: f70e2e06196a ('KEYS: Do preallocation for __key_link()')
    Signed-off-by: Dan Carpenter
    Signed-off-by: David Howells
    cc: stable@vger.kernel.org
    Signed-off-by: Linus Torvalds

    Dan Carpenter
     

14 Jun, 2016

1 commit


03 Jun, 2016

1 commit

  • The values computed during Diffie-Hellman key exchange are often used
    in combination with key derivation functions to create cryptographic
    keys. Add a placeholder for a later implementation to configure a
    key derivation function that will transform the Diffie-Hellman
    result returned by the KEYCTL_DH_COMPUTE command.

    [This patch was stripped down from a patch produced by Mat Martineau that
    had a bug in the compat code - so for the moment Stephan's patch simply
    requires that the placeholder argument must be NULL]

    Original-signed-off-by: Mat Martineau
    Signed-off-by: Stephan Mueller
    Signed-off-by: David Howells
    Signed-off-by: James Morris

    Stephan Mueller
     

05 May, 2016

1 commit

  • Here's a set of patches that changes how certificates/keys are determined
    to be trusted. That's currently a two-step process:

    (1) Up until recently, when an X.509 certificate was parsed - no matter
    the source - it was judged against the keys in .system_keyring,
    assuming those keys to be trusted if they have KEY_FLAG_TRUSTED set
    upon them.

    This has just been changed such that any key in the .ima_mok keyring,
    if configured, may also be used to judge the trustworthiness of a new
    certificate, whether or not the .ima_mok keyring is meant to be
    consulted for whatever process is being undertaken.

    If a certificate is determined to be trustworthy, KEY_FLAG_TRUSTED
    will be set upon a key it is loaded into (if it is loaded into one),
    no matter what the key is going to be loaded for.

    (2) If an X.509 certificate is loaded into a key, then that key - if
    KEY_FLAG_TRUSTED gets set upon it - can be linked into any keyring
    with KEY_FLAG_TRUSTED_ONLY set upon it. This was meant to be the
    system keyring only, but has been extended to various IMA keyrings.
    A user can at will link any key marked KEY_FLAG_TRUSTED into any
    keyring marked KEY_FLAG_TRUSTED_ONLY if the relevant permissions masks
    permit it.

    These patches change that:

    (1) Trust becomes a matter of consulting the ring of trusted keys supplied
    when the trust is evaluated only.

    (2) Every keyring can be supplied with its own manager function to
    restrict what may be added to that keyring. This is called whenever a
    key is to be linked into the keyring to guard against a key being
    created in one keyring and then linked across.

    This function is supplied with the keyring and the key type and
    payload[*] of the key being linked in for use in its evaluation. It
    is permitted to use other data also, such as the contents of other
    keyrings such as the system keyrings.

    [*] The type and payload are supplied instead of a key because as an
    optimisation this function may be called whilst creating a key and
    so may reject the proposed key between preparse and allocation.

    (3) A default manager function is provided that permits keys to be
    restricted to only asymmetric keys that are vouched for by the
    contents of the system keyring.

    A second manager function is provided that just rejects with EPERM.

    (4) A key allocation flag, KEY_ALLOC_BYPASS_RESTRICTION, is made available
    so that the kernel can initialise keyrings with keys that form the
    root of the trust relationship.

    (5) KEY_FLAG_TRUSTED and KEY_FLAG_TRUSTED_ONLY are removed, along with
    key_preparsed_payload::trusted.

    This change also makes it possible in future for userspace to create a private
    set of trusted keys and then to have it sealed by setting a manager function
    where the private set is wholly independent of the kernel's trust
    relationships.

    Further changes in the set involve extracting certain IMA special keyrings
    and making them generally global:

    (*) .system_keyring is renamed to .builtin_trusted_keys and remains read
    only. It carries only keys built in to the kernel. It may be where
    UEFI keys should be loaded - though that could better be the new
    secondary keyring (see below) or a separate UEFI keyring.

    (*) An optional secondary system keyring (called .secondary_trusted_keys)
    is added to replace the IMA MOK keyring.

    (*) Keys can be added to the secondary keyring by root if the keys can
    be vouched for by either ring of system keys.

    (*) Module signing and kexec only use .builtin_trusted_keys and do not use
    the new secondary keyring.

    (*) Config option SYSTEM_TRUSTED_KEYS now depends on ASYMMETRIC_KEY_TYPE as
    that's the only type currently permitted on the system keyrings.

    (*) A new config option, IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY,
    is provided to allow keys to be added to IMA keyrings, subject to the
    restriction that such keys are validly signed by a key already in the
    system keyrings.

    If this option is enabled, but secondary keyrings aren't, additions to
    the IMA keyrings will be restricted to signatures verifiable by keys in
    the builtin system keyring only.

    Signed-off-by: David Howells

    David Howells
     

13 Apr, 2016

3 commits

  • This adds userspace access to Diffie-Hellman computations through a
    new keyctl() syscall command to calculate shared secrets or public
    keys using input parameters stored in the keyring.

    Input key ids are provided in a struct due to the current 5-arg limit
    for the keyctl syscall. Only user keys are supported in order to avoid
    exposing the content of logon or encrypted keys.

    The output is written to the provided buffer, based on the assumption
    that the values are only needed in userspace.

    Future support for other types of key derivation would involve a new
    command, like KEYCTL_ECDH_COMPUTE.

    Once Diffie-Hellman support is included in the crypto API, this code
    can be converted to use the crypto API to take advantage of possible
    hardware acceleration and reduce redundant code.

    Signed-off-by: Mat Martineau
    Signed-off-by: David Howells

    Mat Martineau
     
  • Solved TODO task: big keys saved to shmem file are now stored encrypted.
    The encryption key is randomly generated and saved to payload[big_key_data].

    Signed-off-by: Kirill Marinushkin
    Signed-off-by: David Howells

    Kirill Marinushkin
     
  • The payload preparsing routine for user keys makes a copy of the payload
    provided by the caller and stashes it in the key_preparsed_payload struct for
    ->instantiate() or ->update() to use. However, ->update() takes another copy
    of this to attach to the keyring. ->update() should be using this directly
    and clearing the pointer in the preparse data.

    Signed-off-by: David Howells

    David Howells
     

12 Apr, 2016

2 commits

  • Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED as they're no longer
    meaningful. Also we can drop the trusted flag from the preparse structure.

    Given this, we no longer need to pass the key flags through to
    restrict_link().

    Further, we can now get rid of keyring_restrict_trusted_only() also.

    Signed-off-by: David Howells

    David Howells
     
  • Add a facility whereby proposed new links to be added to a keyring can be
    vetted, permitting them to be rejected if necessary. This can be used to
    block public keys from which the signature cannot be verified or for which
    the signature verification fails. It could also be used to provide
    blacklisting.

    This affects operations like add_key(), KEYCTL_LINK and KEYCTL_INSTANTIATE.

    To this end:

    (1) A function pointer is added to the key struct that, if set, points to
    the vetting function. This is called as:

    int (*restrict_link)(struct key *keyring,
    const struct key_type *key_type,
    unsigned long key_flags,
    const union key_payload *key_payload),

    where 'keyring' will be the keyring being added to, key_type and
    key_payload will describe the key being added and key_flags[*] can be
    AND'ed with KEY_FLAG_TRUSTED.

    [*] This parameter will be removed in a later patch when
    KEY_FLAG_TRUSTED is removed.

    The function should return 0 to allow the link to take place or an
    error (typically -ENOKEY, -ENOPKG or -EKEYREJECTED) to reject the
    link.

    The pointer should not be set directly, but rather should be set
    through keyring_alloc().

    Note that if called during add_key(), preparse is called before this
    method, but a key isn't actually allocated until after this function
    is called.

    (2) KEY_ALLOC_BYPASS_RESTRICTION is added. This can be passed to
    key_create_or_update() or key_instantiate_and_link() to bypass the
    restriction check.

    (3) KEY_FLAG_TRUSTED_ONLY is removed. The entire contents of a keyring
    with this restriction emplaced can be considered 'trustworthy' by
    virtue of being in the keyring when that keyring is consulted.

    (4) key_alloc() and keyring_alloc() take an extra argument that will be
    used to set restrict_link in the new key. This ensures that the
    pointer is set before the key is published, thus preventing a window
    of unrestrictedness. Normally this argument will be NULL.

    (5) As a temporary affair, keyring_restrict_trusted_only() is added. It
    should be passed to keyring_alloc() as the extra argument instead of
    setting KEY_FLAG_TRUSTED_ONLY on a keyring. This will be replaced in
    a later patch with functions that look in the appropriate places for
    authoritative keys.

    Signed-off-by: David Howells
    Reviewed-by: Mimi Zohar

    David Howells
     

18 Mar, 2016

2 commits

  • Pull security layer updates from James Morris:
    "There are a bunch of fixes to the TPM, IMA, and Keys code, with minor
    fixes scattered across the subsystem.

    IMA now requires signed policy, and that policy is also now measured
    and appraised"

    * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (67 commits)
    X.509: Make algo identifiers text instead of enum
    akcipher: Move the RSA DER encoding check to the crypto layer
    crypto: Add hash param to pkcs1pad
    sign-file: fix build with CMS support disabled
    MAINTAINERS: update tpmdd urls
    MODSIGN: linux/string.h should be #included to get memcpy()
    certs: Fix misaligned data in extra certificate list
    X.509: Handle midnight alternative notation in GeneralizedTime
    X.509: Support leap seconds
    Handle ISO 8601 leap seconds and encodings of midnight in mktime64()
    X.509: Fix leap year handling again
    PKCS#7: fix unitialized boolean 'want'
    firmware: change kernel read fail to dev_dbg()
    KEYS: Use the symbol value for list size, updated by scripts/insert-sys-cert
    KEYS: Reserve an extra certificate symbol for inserting without recompiling
    modsign: hide openssl output in silent builds
    tpm_tis: fix build warning with tpm_tis_resume
    ima: require signed IMA policy
    ima: measure and appraise the IMA policy itself
    ima: load policy using path
    ...

    Linus Torvalds
     
  • Pull crypto update from Herbert Xu:
    "Here is the crypto update for 4.6:

    API:
    - Convert remaining crypto_hash users to shash or ahash, also convert
    blkcipher/ablkcipher users to skcipher.
    - Remove crypto_hash interface.
    - Remove crypto_pcomp interface.
    - Add crypto engine for async cipher drivers.
    - Add akcipher documentation.
    - Add skcipher documentation.

    Algorithms:
    - Rename crypto/crc32 to avoid name clash with lib/crc32.
    - Fix bug in keywrap where we zero the wrong pointer.

    Drivers:
    - Support T5/M5, T7/M7 SPARC CPUs in n2 hwrng driver.
    - Add PIC32 hwrng driver.
    - Support BCM6368 in bcm63xx hwrng driver.
    - Pack structs for 32-bit compat users in qat.
    - Use crypto engine in omap-aes.
    - Add support for sama5d2x SoCs in atmel-sha.
    - Make atmel-sha available again.
    - Make sahara hashing available again.
    - Make ccp hashing available again.
    - Make sha1-mb available again.
    - Add support for multiple devices in ccp.
    - Improve DMA performance in caam.
    - Add hashing support to rockchip"

    * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (116 commits)
    crypto: qat - remove redundant arbiter configuration
    crypto: ux500 - fix checks of error code returned by devm_ioremap_resource()
    crypto: atmel - fix checks of error code returned by devm_ioremap_resource()
    crypto: qat - Change the definition of icp_qat_uof_regtype
    hwrng: exynos - use __maybe_unused to hide pm functions
    crypto: ccp - Add abstraction for device-specific calls
    crypto: ccp - CCP versioning support
    crypto: ccp - Support for multiple CCPs
    crypto: ccp - Remove check for x86 family and model
    crypto: ccp - memset request context to zero during import
    lib/mpi: use "static inline" instead of "extern inline"
    lib/mpi: avoid assembler warning
    hwrng: bcm63xx - fix non device tree compatibility
    crypto: testmgr - allow rfc3686 aes-ctr variants in fips mode.
    crypto: qat - The AE id should be less than the maximal AE number
    lib/mpi: Endianness fix
    crypto: rockchip - add hash support for crypto engine in rk3288
    crypto: xts - fix compile errors
    crypto: doc - add skcipher API documentation
    crypto: doc - update AEAD AD handling
    ...

    Linus Torvalds
     

04 Mar, 2016

1 commit


18 Feb, 2016

1 commit

  • The Kconfig currently controlling compilation of this code is:

    config BIG_KEYS
    bool "Large payload keys"

    ...meaning that it currently is not being built as a module by anyone.

    Lets remove the modular code that is essentially orphaned, so that
    when reading the driver there is no doubt it is builtin-only.

    Since module_init translates to device_initcall in the non-modular
    case, the init ordering remains unchanged with this commit.

    We also delete the MODULE_LICENSE tag since all that information
    is already contained at the top of the file in the comments.

    Cc: James Morris
    Cc: "Serge E. Hallyn"
    Cc: keyrings@vger.kernel.org
    Cc: linux-security-module@vger.kernel.org
    Signed-off-by: Paul Gortmaker
    Signed-off-by: David Howells

    Paul Gortmaker
     

10 Feb, 2016

2 commits


28 Jan, 2016

1 commit

  • KEY_FLAG_KEEP should only be applied to a key if the keyring it is being
    linked into has KEY_FLAG_KEEP set.

    To this end, partially revert the following patch:

    commit 1d6d167c2efcfe9539d9cffb1a1be9c92e39c2c0
    Author: Mimi Zohar
    Date: Thu Jan 7 07:46:36 2016 -0500
    KEYS: refcount bug fix

    to undo the change that made it unconditional (Mimi got it right the first
    time).

    Without undoing this change, it becomes impossible to delete, revoke or
    invalidate keys added to keyrings through __key_instantiate_and_link()
    where the keyring has itself been linked to. To test this, run the
    following command sequence:

    keyctl newring foo @s
    keyctl add user a a %:foo
    keyctl unlink %user:a %:foo
    keyctl clear %:foo

    With the commit mentioned above the third and fourth commands fail with
    EPERM when they should succeed.

    Reported-by: Stephen Gallager
    Signed-off-by: David Howells
    Acked-by: Mimi Zohar
    cc: Mimi Zohar
    cc: keyrings@vger.kernel.org
    cc: stable@vger.kernel.org
    Signed-off-by: James Morris

    David Howells
     

27 Jan, 2016

1 commit


20 Jan, 2016

1 commit

  • This fixes CVE-2016-0728.

    If a thread is asked to join as a session keyring the keyring that's already
    set as its session, we leak a keyring reference.

    This can be tested with the following program:

    #include
    #include
    #include
    #include

    int main(int argc, const char *argv[])
    {
    int i = 0;
    key_serial_t serial;

    serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
    "leaked-keyring");
    if (serial < 0) {
    perror("keyctl");
    return -1;
    }

    if (keyctl(KEYCTL_SETPERM, serial,
    KEY_POS_ALL | KEY_USR_ALL) < 0) {
    perror("keyctl");
    return -1;
    }

    for (i = 0; i < 100; i++) {
    serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
    "leaked-keyring");
    if (serial < 0) {
    perror("keyctl");
    return -1;
    }
    }

    return 0;
    }

    If, after the program has run, there something like the following line in
    /proc/keys:

    3f3d898f I--Q--- 100 perm 3f3f0000 0 0 keyring leaked-keyring: empty

    with a usage count of 100 * the number of times the program has been run,
    then the kernel is malfunctioning. If leaked-keyring has zero usages or
    has been garbage collected, then the problem is fixed.

    Reported-by: Yevgeny Pats
    Signed-off-by: David Howells
    Acked-by: Don Zickus
    Acked-by: Prarit Bhargava
    Acked-by: Jarod Wilson
    Signed-off-by: James Morris

    Yevgeny Pats
     

18 Jan, 2016

1 commit

  • Pull security subsystem updates from James Morris:

    - EVM gains support for loading an x509 cert from the kernel
    (EVM_LOAD_X509), into the EVM trusted kernel keyring.

    - Smack implements 'file receive' process-based permission checking for
    sockets, rather than just depending on inode checks.

    - Misc enhancments for TPM & TPM2.

    - Cleanups and bugfixes for SELinux, Keys, and IMA.

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (41 commits)
    selinux: Inode label revalidation performance fix
    KEYS: refcount bug fix
    ima: ima_write_policy() limit locking
    IMA: policy can be updated zero times
    selinux: rate-limit netlink message warnings in selinux_nlmsg_perm()
    selinux: export validatetrans decisions
    gfs2: Invalid security labels of inodes when they go invalid
    selinux: Revalidate invalid inode security labels
    security: Add hook to invalidate inode security labels
    selinux: Add accessor functions for inode->i_security
    security: Make inode argument of inode_getsecid non-const
    security: Make inode argument of inode_getsecurity non-const
    selinux: Remove unused variable in selinux_inode_init_security
    keys, trusted: seal with a TPM2 authorization policy
    keys, trusted: select hash algorithm for TPM2 chips
    keys, trusted: fix: *do not* allow duplicate key options
    tpm_ibmvtpm: properly handle interrupted packet receptions
    tpm_tis: Tighten IRQ auto-probing
    tpm_tis: Refactor the interrupt setup
    tpm_tis: Get rid of the duplicate IRQ probing code
    ...

    Linus Torvalds
     

10 Jan, 2016

1 commit


08 Jan, 2016

1 commit

  • This patch fixes the key_ref leak, removes the unnecessary KEY_FLAG_KEEP
    test before setting the flag, and cleans up the if/then brackets style
    introduced in commit:
    d3600bc KEYS: prevent keys from being removed from specified keyrings

    Reported-by: David Howells
    Signed-off-by: Mimi Zohar
    Acked-by: David Howells

    Mimi Zohar
     

26 Dec, 2015

1 commit


20 Dec, 2015

3 commits

  • TPM2 supports authorization policies, which are essentially
    combinational logic statements repsenting the conditions where the data
    can be unsealed based on the TPM state. This patch enables to use
    authorization policies to seal trusted keys.

    Two following new options have been added for trusted keys:

    * 'policydigest=': provide an auth policy digest for sealing.
    * 'policyhandle=': provide a policy session handle for unsealing.

    If 'hash=' option is supplied after 'policydigest=' option, this
    will result an error because the state of the option would become
    mixed.

    Signed-off-by: Jarkko Sakkinen
    Tested-by: Colin Ian King
    Reviewed-by: Mimi Zohar
    Acked-by: Peter Huewe

    Jarkko Sakkinen
     
  • Added 'hash=' option for selecting the hash algorithm for add_key()
    syscall and documentation for it.

    Added entry for sm3-256 to the following tables in order to support
    TPM_ALG_SM3_256:

    * hash_algo_name
    * hash_digest_size

    Includes support for the following hash algorithms:

    * sha1
    * sha256
    * sha384
    * sha512
    * sm3-256

    Signed-off-by: Jarkko Sakkinen
    Tested-by: Colin Ian King
    Reviewed-by: James Morris
    Reviewed-by: Mimi Zohar
    Acked-by: Peter Huewe

    Jarkko Sakkinen
     
  • The trusted keys option parsing allows specifying the same option
    multiple times. The last option value specified is used.

    This is problematic because:

    * No gain.
    * This makes complicated to specify options that are dependent on other
    options.

    This patch changes the behavior in a way that option can be specified
    only once.

    Reported-by: James Morris James Morris
    Reviewed-by: Mimi Zohar
    Signed-off-by: Jarkko Sakkinen
    Acked-by: Peter Huewe

    Jarkko Sakkinen
     

19 Dec, 2015

1 commit

  • This fixes CVE-2015-7550.

    There's a race between keyctl_read() and keyctl_revoke(). If the revoke
    happens between keyctl_read() checking the validity of a key and the key's
    semaphore being taken, then the key type read method will see a revoked key.

    This causes a problem for the user-defined key type because it assumes in
    its read method that there will always be a payload in a non-revoked key
    and doesn't check for a NULL pointer.

    Fix this by making keyctl_read() check the validity of a key after taking
    semaphore instead of before.

    I think the bug was introduced with the original keyrings code.

    This was discovered by a multithreaded test program generated by syzkaller
    (http://github.com/google/syzkaller). Here's a cleaned up version:

    #include
    #include
    #include
    void *thr0(void *arg)
    {
    key_serial_t key = (unsigned long)arg;
    keyctl_revoke(key);
    return 0;
    }
    void *thr1(void *arg)
    {
    key_serial_t key = (unsigned long)arg;
    char buffer[16];
    keyctl_read(key, buffer, 16);
    return 0;
    }
    int main()
    {
    key_serial_t key = add_key("user", "%", "foo", 3, KEY_SPEC_USER_KEYRING);
    pthread_t th[5];
    pthread_create(&th[0], 0, thr0, (void *)(unsigned long)key);
    pthread_create(&th[1], 0, thr1, (void *)(unsigned long)key);
    pthread_create(&th[2], 0, thr0, (void *)(unsigned long)key);
    pthread_create(&th[3], 0, thr1, (void *)(unsigned long)key);
    pthread_join(th[0], 0);
    pthread_join(th[1], 0);
    pthread_join(th[2], 0);
    pthread_join(th[3], 0);
    return 0;
    }

    Build as:

    cc -o keyctl-race keyctl-race.c -lkeyutils -lpthread

    Run as:

    while keyctl-race; do :; done

    as it may need several iterations to crash the kernel. The crash can be
    summarised as:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
    IP: [] user_read+0x56/0xa3
    ...
    Call Trace:
    [] keyctl_read_key+0xb6/0xd7
    [] SyS_keyctl+0x83/0xe0
    [] entry_SYSCALL_64_fastpath+0x12/0x6f

    Reported-by: Dmitry Vyukov
    Signed-off-by: David Howells
    Tested-by: Dmitry Vyukov
    Cc: stable@vger.kernel.org
    Signed-off-by: James Morris

    David Howells
     

15 Dec, 2015

1 commit

  • Userspace should not be allowed to remove keys from certain keyrings
    (eg. blacklist), though the keys themselves can expire.

    This patch defines a new key flag named KEY_FLAG_KEEP to prevent
    userspace from being able to unlink, revoke, invalidate or timed
    out a key on a keyring. When this flag is set on the keyring, all
    keys subsequently added are flagged.

    In addition, when this flag is set, the keyring itself can not be
    cleared.

    Signed-off-by: Mimi Zohar
    Cc: David Howells

    Mimi Zohar
     

25 Nov, 2015

1 commit

  • If a user key gets negatively instantiated, an error code is cached in the
    payload area. A negatively instantiated key may be then be positively
    instantiated by updating it with valid data. However, the ->update key
    type method must be aware that the error code may be there.

    The following may be used to trigger the bug in the user key type:

    keyctl request2 user user "" @u
    keyctl add user user "a" @u

    which manifests itself as:

    BUG: unable to handle kernel paging request at 00000000ffffff8a
    IP: [] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046
    PGD 7cc30067 PUD 0
    Oops: 0002 [#1] SMP
    Modules linked in:
    CPU: 3 PID: 2644 Comm: a.out Not tainted 4.3.0+ #49
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    task: ffff88003ddea700 ti: ffff88003dd88000 task.ti: ffff88003dd88000
    RIP: 0010:[] [] __call_rcu.constprop.76+0x1f/0x280
    [] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046
    RSP: 0018:ffff88003dd8bdb0 EFLAGS: 00010246
    RAX: 00000000ffffff82 RBX: 0000000000000000 RCX: 0000000000000001
    RDX: ffffffff81e3fe40 RSI: 0000000000000000 RDI: 00000000ffffff82
    RBP: ffff88003dd8bde0 R08: ffff88007d2d2da0 R09: 0000000000000000
    R10: 0000000000000000 R11: ffff88003e8073c0 R12: 00000000ffffff82
    R13: ffff88003dd8be68 R14: ffff88007d027600 R15: ffff88003ddea700
    FS: 0000000000b92880(0063) GS:ffff88007fd00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 00000000ffffff8a CR3: 000000007cc5f000 CR4: 00000000000006e0
    Stack:
    ffff88003dd8bdf0 ffffffff81160a8a 0000000000000000 00000000ffffff82
    ffff88003dd8be68 ffff88007d027600 ffff88003dd8bdf0 ffffffff810a39e5
    ffff88003dd8be20 ffffffff812a31ab ffff88007d027600 ffff88007d027620
    Call Trace:
    [] kfree_call_rcu+0x15/0x20 kernel/rcu/tree.c:3136
    [] user_update+0x8b/0xb0 security/keys/user_defined.c:129
    [< inline >] __key_update security/keys/key.c:730
    [] key_create_or_update+0x291/0x440 security/keys/key.c:908
    [< inline >] SYSC_add_key security/keys/keyctl.c:125
    [] SyS_add_key+0x101/0x1e0 security/keys/keyctl.c:60
    [] entry_SYSCALL_64_fastpath+0x12/0x6a arch/x86/entry/entry_64.S:185

    Note the error code (-ENOKEY) in EDX.

    A similar bug can be tripped by:

    keyctl request2 trusted user "" @u
    keyctl add trusted user "a" @u

    This should also affect encrypted keys - but that has to be correctly
    parameterised or it will fail with EINVAL before getting to the bit that
    will crashes.

    Reported-by: Dmitry Vyukov
    Signed-off-by: David Howells
    Acked-by: Mimi Zohar
    Signed-off-by: James Morris

    David Howells
     

06 Nov, 2015

1 commit

  • Pull security subsystem update from James Morris:
    "This is mostly maintenance updates across the subsystem, with a
    notable update for TPM 2.0, and addition of Jarkko Sakkinen as a
    maintainer of that"

    * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (40 commits)
    apparmor: clarify CRYPTO dependency
    selinux: Use a kmem_cache for allocation struct file_security_struct
    selinux: ioctl_has_perm should be static
    selinux: use sprintf return value
    selinux: use kstrdup() in security_get_bools()
    selinux: use kmemdup in security_sid_to_context_core()
    selinux: remove pointless cast in selinux_inode_setsecurity()
    selinux: introduce security_context_str_to_sid
    selinux: do not check open perm on ftruncate call
    selinux: change CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE default
    KEYS: Merge the type-specific data with the payload data
    KEYS: Provide a script to extract a module signature
    KEYS: Provide a script to extract the sys cert list from a vmlinux file
    keys: Be more consistent in selection of union members used
    certs: add .gitignore to stop git nagging about x509_certificate_list
    KEYS: use kvfree() in add_key
    Smack: limited capability for changing process label
    TPM: remove unnecessary little endian conversion
    vTPM: support little endian guests
    char: Drop owner assignment from i2c_driver
    ...

    Linus Torvalds
     

21 Oct, 2015

3 commits

  • Merge the type-specific data with the payload data into one four-word chunk
    as it seems pointless to keep them separate.

    Use user_key_payload() for accessing the payloads of overloaded
    user-defined keys.

    Signed-off-by: David Howells
    cc: linux-cifs@vger.kernel.org
    cc: ecryptfs@vger.kernel.org
    cc: linux-ext4@vger.kernel.org
    cc: linux-f2fs-devel@lists.sourceforge.net
    cc: linux-nfs@vger.kernel.org
    cc: ceph-devel@vger.kernel.org
    cc: linux-ima-devel@lists.sourceforge.net

    David Howells
     
  • key->description and key->index_key.description are same because
    they are unioned. But, for readability, using same name for
    duplication and validation seems better.

    Signed-off-by: Insu Yun
    Signed-off-by: David Howells

    Insu Yun
     
  • There is no need to make a flag to tell that this memory is allocated by
    kmalloc or vmalloc. Just use kvfree to free the memory.

    Signed-off-by: Geliang Tang
    Signed-off-by: David Howells

    Geliang Tang
     

19 Oct, 2015

1 commit

  • If request_key() is used to find a keyring, only do the search part - don't
    do the construction part if the keyring was not found by the search. We
    don't really want keyrings in the negative instantiated state since the
    rejected/negative instantiation error value in the payload is unioned with
    keyring metadata.

    Now the kernel gives an error:

    request_key("keyring", "#selinux,bdekeyring", "keyring", KEY_SPEC_USER_SESSION_KEYRING) = -1 EPERM (Operation not permitted)

    Signed-off-by: David Howells

    David Howells