Merge tag 'keys-next-20160505' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into next

Merge branch 'keys-trust' into keys-next

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

Merge branch 'keys-trust' into keys-next

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 <dhowells@redhat.com>

show more ...

Merge branch 'master' into for-next

Sync with Linus' tree so that patches against newer codebase can be applied.

Signed-off-by: Jiri Kosina <jkosina@suse.cz>

KEYS: Add a facility to restrict new links into a keyring

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

KEYS: Add a facility to restrict new links into a keyring

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 <dhowells@redhat.com>
Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com>

show more ...

Merge tag 'v4.5' into next

Merge with Linux 4.5 to get PROPERTY_ENTRY_INTEGER() that is needed to
fix pxa/raumfeld rotary encoder properties.

Orangefs: merge to v4.5

Merge tag 'v4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into current

Linux 4.5

Merge branch 'topic/update-bits' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap into asoc-rcar

Merge remote-tracking branch 'linusw-gpio/for-next' into devm_gpiochip

Base for demv_gpiochip_add_data() and devm_gpiochip_remove().

Merge tag 'v4.5-rc5' into asoc-mtk

Linux 4.5-rc5

Merge tag 'topic/drm-misc-2016-02-12' into drm-intel-next-queued

Backmerge to get at the new encoder_mask support in atomic helpers.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Merge branch 'topic/acpi' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi into spi-pxa2xx

Merge branch 'x86/urgent' into x86/mm, to pick up dependent fix

Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge branch 'linus' into efi/core, to refresh the branch and to pick up recent fixes

Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

Merge tag 'v4.5-rc1' into x86/asm, to refresh the branch before merging new changes

Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge branch 'enable-devices' into omap-for-v4.5/fixes

Merge tag 'v4.5-rc1' into patchwork

Linux 4.5-rc1

* tag 'v4.5-rc1': (11309 commits)
Linux 4.5-rc1
ideapad-laptop: Add Lenovo Yoga 700 to no_hw_rfkill dmi list
MAINTAINERS: Combine multiple te

Merge tag 'v4.5-rc1' into patchwork

Linux 4.5-rc1

* tag 'v4.5-rc1': (11309 commits)
Linux 4.5-rc1
ideapad-laptop: Add Lenovo Yoga 700 to no_hw_rfkill dmi list
MAINTAINERS: Combine multiple telemetry entries
intel_telemetry_debugfs: Fix unused warnings in telemetry debugfs
vmstat: Remove BUG_ON from vmstat_update
MIPS: zboot: Add support for serial debug using the PROM
MIPS: zboot: Avoid useless rebuilds
MIPS: BMIPS: Enable ARCH_WANT_OPTIONAL_GPIOLIB
MIPS: bcm63xx: nvram: Remove unused bcm63xx_nvram_get_psi_size() function
MIPS: bcm963xx: Update bcm_tag field image_sequence
MIPS: bcm963xx: Move extended flash address to bcm_tag header file
MIPS: bcm963xx: Move Broadcom BCM963xx image tag data structure
MIPS: bcm63xx: nvram: Use nvram structure definition from header file
MIPS: bcm963xx: Add Broadcom BCM963xx board nvram data structure
MAINTAINERS: Add KVM for MIPS entry
MIPS: KVM: Add missing newline to kvm_err()
MIPS: Move KVM specific opcodes into asm/inst.h
MIPS: KVM: Use cacheops.h definitions
MIPS: Break down cacheops.h definitions
MIPS: Use EXCCODE_ constants with set_except_vector()
...

show more ...

Merge tag 'v4.4'

Linux 4.4

Orangefs: Merge tag 'v4.4-rc1' into for-next

Linux 4.4-rc1

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security

Pull security subsystem update from James Morris:
"A CVE fix and a maintainers file update"

* 'for-

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security

Pull security subsystem update from James Morris:
"A CVE fix and a maintainers file update"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
KEYS: Fix keyring ref leak in join_session_keyring()
Fix the MAINTAINERS record for the certs/ directory

show more ...

KEYS: Fix keyring ref leak in join_session_keyring()

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 ref

KEYS: Fix keyring ref leak in join_session_keyring()

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 <stddef.h>
#include <stdio.h>
#include <sys/types.h>
#include <keyutils.h>

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 <yevgeny@perception-point.io>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Don Zickus <dzickus@redhat.com>
Acked-by: Prarit Bhargava <prarit@redhat.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>

show more ...

Merge branch 'next' into for-linus

Prepare first round of input updates for 4.5 merge window.

Merge back earlier 'pm-domains' material for v4.5.

Merge branch 'linus' into x86/cleanups

Pull in upstream changes so we can apply depending patches.

Merge branch 'linus' into x86/apic

Pull in update changes so we can apply conflicting patches