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

LoadPin is a Linux Security Module that ensures all kernel-loaded files

(modules, firmware, etc) all originate from the same filesystem, with

the expectation that such a filesystem is backed by a read-only device

such as dm-verity or CDROM. This allows systems that have a verified

and/or unchangeable filesystem to enforce module and firmware loading

restrictions without needing to sign the files individually.

The LSM is selectable at build-time with CONFIG_SECURITY_LOADPIN, and

can be controlled at boot-time with the kernel command line option

"loadpin.enabled". By default, it is enabled, but can be disabled at

boot ("loadpin.enabled=0").

LoadPin starts pinning when it sees the first file loaded. If the

block device backing the filesystem is not read-only, a sysctl is

created to toggle pinning: /proc/sys/kernel/loadpin/enabled. (Having

a mutable filesystem means pinning is mutable too, but having the

sysctl allows for easy testing on systems with a mutable filesystem.)

     A process must have search permission on the key for this function to be

     successful.

 (*) Compute a Diffie-Hellman shared secret or public key

       long keyctl(KEYCTL_DH_COMPUTE, struct keyctl_dh_params *params,

		   char *buffer, size_t buflen);

     The params struct contains serial numbers for three keys:

	 - The prime, p, known to both parties

	 - The local private key

	 - The base integer, which is either a shared generator or the

	   remote public key

     The value computed is:

	result = base ^ private (mod prime)

     If the base is the shared generator, the result is the local

     public key.  If the base is the remote public key, the result is

     the shared secret.

     The buffer length must be at least the length of the prime, or zero.

     If the buffer length is nonzero, the length of the result is

     returned when it is successfully calculated and copied in to the

     buffer. When the buffer length is zero, the minimum required

     buffer length is returned.

     This function will return error EOPNOTSUPP if the key type is not

     supported, error ENOKEY if the key could not be found, or error

     EACCES if the key is not readable by the caller.

===============

KERNEL SERVICES

	struct key *keyring_alloc(const char *description, uid_t uid, gid_t gid,

				  const struct cred *cred,

				  key_perm_t perm,

				  int (*restrict_link)(struct key *,

						       const struct key_type *,

						       unsigned long,

						       const union key_payload *),

				  unsigned long flags,

				  struct key *dest);

    KEY_ALLOC_NOT_IN_QUOTA in flags if the keyring shouldn't be accounted

    towards the user's quota).  Error ENOMEM can also be returned.

    If restrict_link not NULL, it should point to a function that will be

    called each time an attempt is made to link a key into the new keyring.

    This function is called to check whether a key may be added into the keying

    or not.  Callers of key_create_or_update() within the kernel can pass

    KEY_ALLOC_BYPASS_RESTRICTION to suppress the check.  An example of using

    this is to manage rings of cryptographic keys that are set up when the

    kernel boots where userspace is also permitted to add keys - provided they

    can be verified by a key the kernel already has.

    When called, the restriction function will be passed the keyring being

    added to, the key flags value and the type and payload of the key being

    added.  Note that when a new key is being created, this is called between

    payload preparsing and actual key creation.  The function should return 0

    to allow the link or an error to reject it.

    A convenience function, restrict_link_reject, exists to always return

    -EPERM to in this case.

(*) To check the validity of a key, this function can be called:

S:	Supported

F:	security/apparmor/

LOADPIN SECURITY MODULE

M:	Kees Cook <keescook@chromium.org>

T:	git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git lsm/loadpin

S:	Supported

F:	security/loadpin/

YAMA SECURITY MODULE

M:	Kees Cook <keescook@chromium.org>

T:	git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git yama/tip

#include <linux/kernel.h>

#include <linux/mm.h>

#include <linux/efi.h>

#include <linux/verify_pefile.h>

#include <keys/system_keyring.h>

#include <linux/verification.h>

#include <asm/bootparam.h>

#include <asm/setup.h>

#ifdef CONFIG_KEXEC_BZIMAGE_VERIFY_SIG

static int bzImage64_verify_sig(const char *kernel, unsigned long kernel_len)

{

	bool trusted;

	int ret;

	ret = verify_pefile_signature(kernel, kernel_len,

				      system_trusted_keyring,

				      VERIFYING_KEXEC_PE_SIGNATURE,

				      &trusted);

	if (ret < 0)

		return ret;

	if (!trusted)

		return -EKEYREJECTED;

	return 0;

	return verify_pefile_signature(kernel, kernel_len,

				       NULL,

				       VERIFYING_KEXEC_PE_SIGNATURE);

}

#endif

config SYSTEM_TRUSTED_KEYRING

	bool "Provide system-wide ring of trusted keys"

	depends on KEYS

	depends on ASYMMETRIC_KEY_TYPE

	help

	  Provide a system keyring to which trusted keys can be added.  Keys in

	  the keyring are considered to be trusted.  Keys may be added at will

	  This is the number of bytes reserved in the kernel image for a

	  certificate to be inserted.

config SECONDARY_TRUSTED_KEYRING

	bool "Provide a keyring to which extra trustable keys may be added"

	depends on SYSTEM_TRUSTED_KEYRING

	help

	  If set, provide a keyring to which extra keys may be added, provided

	  those keys are not blacklisted and are vouched for by a key built

	  into the kernel or already in the secondary trusted keyring.

endmenu